DORA for SaaS Vendors to European Banks: The Subcontractor Register, Exit Strategy, and Pen-Test Reports You Now Need

If your SaaS product touches any data or process inside a European bank, insurer, or investment firm, you already are a subject of the Digital Operational Resilience Act — whether your contracts acknowledge it or not. DORA became fully enforceable in January 2025, and the operational cascade has been arriving at vendor inboxes ever since: due-diligence questionnaires, updated contract annexes, requests for penetration-test summaries, and the occasional subcontractor audit notice.

Most of the guidance published about DORA is written for the financial institutions themselves. This post is the other side of that conversation: what a mid-size SaaS company — one that has a handful of bank or insurance clients but has never had a compliance team — actually needs to put in place to satisfy Articles 28–30 without rerouting its entire engineering roadmap.

Why SaaS Vendors Are Now ICT Third-Party Providers Under DORA

DORA defines an ICT third-party service provider as any entity that delivers digital and data services on a continuous basis. If your product is a SaaS application used by a financial entity's staff or systems, that definition covers you. The obligations do not depend on your own regulatory status; they flow from the financial entity's contractual relationship with you.

Under Article 28, every financial entity subject to DORA must maintain a complete register of all ICT third-party providers, including their subcontractors that handle critical or important functions. Your customer's compliance team needs information from you to complete that register — and supervisors from the European Central Bank, national competent authorities, or ESMA can request a copy of it at any time.

This is the mechanism that makes DORA a vendor problem, not just a bank problem. When your customer gets an ECB questionnaire about their critical ICT providers, they pass a portion of that questionnaire down to you.

What the ICT Third-Party Register Actually Asks for

The register format is standardised across the EU. The European Supervisory Authorities published a joint template in 2024 and your customers are required to use it. When a bank contacts you requesting register data, they will typically want:

• Entity identification: your legal name, LEI code (or VAT if no LEI), country of establishment, and the specific SaaS service name and version in scope
• Service classification: whether your service supports a critical or important function at the financial entity (this is their determination, but they may ask you to confirm the functional category)
• Subcontractor chain: the names and countries of any ICT subcontractors you use to deliver the service — cloud providers, CDN vendors, database-as-a-service, monitoring tools — down to the first tier that handles financial entity data
• Data residency: the countries where data is stored and processed, including any jurisdictions outside the EU
• Concentration indicators: whether your service is used by multiple financial entities (which affects the systemic risk classification)
• Incident history: any ICT-related incidents in the past 12 months that affected service availability or data integrity for financial entity clients

The practical implication: you need a maintained, version-controlled internal document that tracks all of this information. When a customer sends a register request, you fill their template from your internal document — not from memory and not from a panicked Slack thread. A simple structured document (JSON or YAML in your infrastructure repository works well) that is reviewed quarterly and owned by a named person is all it takes.

The Exit-Strategy Clause: What Your Contract Actually Requires

Article 30 of DORA specifies mandatory content for contracts between financial entities and their critical ICT third-party providers. If your service is classified as supporting a critical or important function, your customer is required to include exit-strategy provisions that go well beyond the standard termination clauses you probably already have.

The exit-strategy clause is not just about the right to terminate. It requires your customer to be able to exit the relationship without material disruption to their operations — and that means you must be able to support the transition. Specifically:

Data portability and export: Your contract must specify how the financial entity can extract all of their data in a usable format within a defined timeframe. "We will provide a data export on request" is not sufficient. The clause should name the format (standard open formats preferred — CSV, JSON, Parquet, not a proprietary dump), the completeness criteria (all historical records, all metadata, all audit logs), and the maximum time to delivery.

Transition support period: Many updated contracts now require the vendor to provide a minimum period of continued operation and technical support after notice of termination — typically 12 months for critical services. This gives the financial entity time to migrate without a cliff edge. You need to know whether your service terms include this and whether your infrastructure can honour it.

Runbook access: The exit clause may also require you to provide operational documentation sufficient for the financial entity or a replacement vendor to operate the service independently. For a SaaS product this is unusual, but some systemically important functions are treated as infrastructure-like, and supervisors are reading these clauses carefully.

If your customer has sent you a contract amendment in the last 18 months, it almost certainly contains a DORA-motivated exit-strategy annex. Read it. Confirm that your technical capabilities can actually deliver on what it says. If there is a gap — for example, your data export pipeline does not currently produce a complete historical export within the specified timeframe — that is a backlog item with a compliance deadline attached, not a nice-to-have.

Our software architecture and technical consulting services frequently include a DORA contract gap analysis as part of engagements with SaaS companies entering the European financial sector. The gap between what contracts promise and what the codebase can deliver is almost always larger than the engineering team realises.

Threat-Led Penetration Testing: The Cadence and the Evidence

DORA introduces a specific type of security testing called threat-led penetration testing (TLPT), governed by a framework called TIBER-EU (and its national equivalents — TIBER-DE, CBEST in the UK). TLPT is mandatory only for financial entities that are classified as systemically important, and it applies directly to them rather than their vendors. However, critical ICT third-party providers can be brought into scope as part of a TLPT exercise at the financial entity's request.

What this means for a SaaS vendor: you may receive a request from a bank client to participate in a TLPT exercise that targets your infrastructure, APIs, or the integration points between your system and theirs. This is not the same as a standard penetration test. A TLPT engagement is conducted by certified threat intelligence providers, follows a structured kill-chain methodology, and produces a report format specifically designed for regulatory review.

If you have existing penetration test reports, the following questions determine their usefulness in a DORA context:

1. Was the test conducted by an independent qualified provider, not your internal security team?
2. Does the report cover the specific service and environment your financial entity client uses, not just your general production environment?
3. Is the report dated within the last 12 months? (Financial entities are typically required to verify their critical providers' security posture annually.)
4. Does the report include scope definition, methodology, findings classified by severity, and a remediation timeline?

If the answer to any of these is no, you will not be able to hand the report to a bank auditor and have it accepted. You will need a new test. Plan for 6–10 weeks from scope agreement to final report, and budget accordingly — qualified TLPT providers charge significantly more than commodity penetration testing firms.

Getting Audit-Ready Without Burning the Engineering Roadmap

The practical challenge for a 10-to-50-person SaaS company is that none of this is core product work. Here is a sequenced approach that minimises disruption:

Month 1 — inventory and gap assessment: Map every financial entity client and confirm whether your service is classified as critical or important. Pull the contracts and identify any DORA-motivated amendments. Inventory your current subcontractor chain (cloud providers, SaaS dependencies). Identify the gaps with the nearest hard deadlines.

Month 2 — register data and documentation: Create the internal register document. Write or formalise the data export runbook. Confirm your export pipeline against any contractual specifications.

Month 3 — security testing: Commission an independent penetration test if your last one is out of date or out of scope. Confirm with your customers' vendor management teams what format they need for the report.

Ongoing — quarterly review: Assign a named owner for the internal register. Add a calendar reminder to verify that subcontractor information and incident logs are current. This does not need a dedicated compliance hire — it needs a documented owner and 4 hours per quarter.

Articles 28–30 Compliance Checklist

A condensed reference for the items described above, mapped to the regulation:

• Article 28(2): Maintain and provide register data in the ESA template format
• Article 28(4)(c): Confirm subcontractor chain for first-tier ICT dependencies
• Article 30(2)(e): Data portability clause with format, completeness, and delivery timeframe specified
• Article 30(2)(f): Transition support period defined and operationally supported
• Article 30(2)(g): Operational documentation accessible for transition scenarios
• Article 26(3): Annual independent security testing; TLPT readiness for critical providers
• Article 19: Incident logging and classification sufficient to support the 24-hour initial report financial entities must file to their supervisors

The Vendor Who Arrives Prepared Wins the Deal

Financial entities are not just checking DORA boxes with their ICT provider questionnaires — they are also making procurement decisions. A vendor who responds to a due-diligence request with a complete, clearly structured register entry, a current penetration test report, and a contract annex that actually matches their technical capabilities is a vendor that makes the compliance officer's job easy. That vendor keeps the deal and often gets the next one.

If you are working through a DORA vendor assessment, or need help auditing whether your contracts, runbooks, and security testing cadence meet the requirements, reach out at hello@wolf-tech.io. Wolf-Tech works directly with SaaS teams navigating European regulatory requirements — without the overhead of a large consultancy and without the delay of a procurement process.

More on compliance architecture and vendor-side regulatory preparation at wolf-tech.io.