DORA for ICT Third-Party Providers: What SaaS Vendors Must Test (2026 Guide)

Plenty of B2B SaaS and cloud vendors read DORA, saw ‘financial entities’, and assumed it was someone else's problem. It is not. If your product supports a function at an EU bank, insurer, payment firm or investment house, DORA's third-party rules reach you — through the contract your customer is now required to put in place.

This is the vendor's side of DORA: how the obligation flows to you, what your customers must now demand, and specifically what penetration testing evidence you need ready before their third-party risk team asks — because they will.

DORA governs the financial entity, but Articles 28-30 make managing ICT third-party risk a core obligation — which means the requirements land on you through the contract. Your customers must keep a register of information covering every ICT provider, secure specific contractual provisions (audit and access rights, security requirements, incident cooperation, sub-outsourcing controls, and exit strategies), and pay closer attention where you support a critical or important function.

The largest, most systemic providers can additionally be designated critical ICT third-party providers and fall under a direct EU oversight framework run by the European Supervisory Authorities. Most vendors will not be designated — but nearly all will feel DORA through customer contracts and questionnaires.

A financial entity's third-party risk team cannot simply take ‘we take security seriously’ for an answer any more — DORA requires them to evidence your resilience. In practice that means requests for: the scope and results of penetration testing on the service you provide; proof that exploitable findings were remediated and re-tested; your testing cadence, especially after significant change; and how quickly you would detect and report an incident that touches their data.

Vendors who treat this as a once-a-year PDF end up stuck in review, because the PDF is stale by the time procurement reads it. Vendors who can produce current, mapped evidence on demand close reviews fast.

Scope the service the way your customer's function depends on it. That means the external surface they reach over the internet and the internal surface behind your own perimeter — the internal APIs, admin planes, and, for multi-tenant SaaS, the isolation controls that keep one customer's data away from another's. Tenant-isolation failures are the finding a financial customer fears most, and the one a shallow external-only test never reaches.

Test at both the application and network layers, re-test every exploitable finding after you fix it, and keep the evidence in a form you can share — scope, proof, remediation, and re-test, mapped to the risk each one covers.

The vendors who turn DORA into a sales advantage are the ones whose product is tested continuously, so the evidence pack is always current and every review starts from a green baseline. Instead of scrambling to commission a test each time a big financial prospect sends a questionnaire, you hand over living evidence and keep the deal moving.

For vendors, Pentestas runs as pentesting as a service your financial-entity customers can point to directly: an AI penetration testing system that tests your product after every release. It is penetration testing with AI at the core — penetration testing with Claude for deep exploit reasoning and penetration testing with DeepSeek for high-volume regression — and as a B2B SaaS pentest it produces the mapped, re-tested evidence a bank's third-party risk team actually asks for.

Bottom line: DORA has no vendor exemption. If you sell to EU financial entities, the obligation reaches you through their contracts, and their third-party risk teams will ask for penetration testing evidence on your product. Keep that evidence continuous, full-scope and mapped, and DORA becomes a reason customers pick you rather than a deal-blocker.