DORA for SaaS Companies: When You Are an ICT Service Provider to a European Bank
Alexander Sverdlov
Security Analyst
Key Takeaways
- DORA has been in direct force across the EU since 17 January 2025. Implementation is no longer hypothetical; banks and insurers have already started rewriting all their ICT supplier contracts.
- If your SaaS provides any service to an EU financial entity, you fall under Article 30 contractual obligations. The bank you sell to is required by law to embed specific clauses in your contract.
- A small number of SaaS providers will be designated "Critical ICT third-party providers" (CTTP) by the European Supervisory Authorities (ESAs) and placed under direct EU oversight. The rest are governed indirectly through customer contracts.
- DORA's contract requirements are more prescriptive than NIS2's supply chain language. There are mandatory clauses you cannot negotiate out, such as right-to-audit, exit strategy, and sub-contracting controls.
- Threat-Led Penetration Testing (TLPT) requirements apply to your customers; if you support critical functions, you may have to participate in their TLPT.
- SOC 2 Type 2 covers about 60 percent of DORA's expectations. The gap is mostly in operational resilience testing, exit strategies, and sub-contracting governance.
In March we got a call from the Chief Operating Officer of a US-based SaaS that provides client onboarding and KYC tooling to mid-sized European banks. They had been winning EU customers steadily for three years. In the past four months they had received five separate contract amendments, each between 18 and 34 pages, each titled with some variation of "DORA-aligned ICT supplier framework." Each was a different bank's interpretation of the same regulation.
The COO had three problems. First, the amendments contained mandatory clauses that conflicted across customers (one bank required 4-hour incident notification, another required 24-hour notification with specific language; both demanded their version). Second, the cumulative cost of meeting every clause was higher than the smaller customers were worth. Third, his largest customer had hinted that they might add him to their internal list of "critical" suppliers, which would mean dramatically more onerous obligations.
This is the typical DORA conversation in 2026. The regulation is real, the customers are serious, the contracts are inconsistent, and the SaaS in the middle has to figure out how to comply efficiently rather than five times over. Below is the framework we use with clients in this position.
Step One
What DORA Actually Is, From a SaaS Perspective
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is a horizontal regulation that applies to all financial entities operating in the EU, plus their critical ICT third-party service providers. The regulation was published in December 2022, entered into application on 17 January 2025, and is now actively enforced by the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA), collectively the European Supervisory Authorities (ESAs).
As a SaaS, you are likely not directly in scope as a "financial entity." You are likely in scope as an "ICT third-party service provider" through Article 30 (the contractual provisions section) and potentially through Articles 31 to 44 (the oversight framework for critical providers).
Step Two
Article 30: The Mandatory Contract Clauses You Cannot Negotiate Out
Article 30 of DORA enumerates a long list of contractual provisions that any contract between a financial entity and an ICT third-party service provider must contain. These are not best-practice clauses; they are statutory requirements imposed on the financial entity. If their contract with you does not contain them, the financial entity is in breach of DORA, irrespective of your performance.
For "critical or important functions" (defined as functions that, if disrupted, would materially impair the financial entity's services or its ability to comply with regulatory obligations), Article 30(3) imposes additional mandatory provisions. Most SaaS that serve banks fall under this stricter regime because almost any system that processes customer data, transactions, or supports operations qualifies.
The most operationally consequential of these for a SaaS are the right-to-audit (item 5), the support during incidents at no additional cost (item 9), and the comprehensive exit strategy (item 12). The right-to-audit is non-negotiable in principle but typically negotiated in practice (most banks accept SOC 2 or ISO 27001 reports plus an annual question-and-answer session in lieu of on-premise audits). The "no additional cost" support clause is the one that reduces SaaS pricing power during incidents - you cannot bill emergency engineering as professional services. The exit strategy clause requires you to maintain documentation, code, and data export tooling such that a customer could leave you and migrate to a competitor without your engineering team's cooperation.
Step Three
The "Critical ICT Third-Party Provider" Designation
A small number of ICT providers will be designated as Critical ICT Third-Party Providers (CTTPs) under Article 31 and placed under direct EU supervision. The designation is decided by the ESAs based on factors including:
- Total turnover and number of EU financial entities served
- Substitutability (how easily customers could replace you)
- Systemic dependencies (whether disruption would impact the broader financial system)
- Whether you provide services for critical or important functions
- Geographic concentration risk
In practice, the first CTTP designations published in 2025 covered hyperscale cloud providers (AWS, Microsoft, Google), major infrastructure companies (IBM, Oracle), and a handful of specialized firms (Bloomberg, Refinitiv). Most SaaS will not be designated CTTPs in the foreseeable future. The threshold is high, deliberately, because the consequences are significant: direct supervision, on-site inspections, mandatory remediation plans, and fines up to 1 percent of average daily worldwide turnover for non-cooperation.
The more practical concern for most SaaS is whether your customer's own classification of your services as "critical or important" triggers the stricter Article 30(3) clauses. This is decided by the financial entity, not the SaaS, based on the financial entity's own resilience analysis. If your service supports anything material (KYC, AML, payments, trading, customer onboarding, fraud detection, regulatory reporting), expect to be classified as supporting a critical function.
Step Four
Threat-Led Penetration Testing and Operational Resilience Testing
DORA Articles 24 to 26 require financial entities to conduct Threat-Led Penetration Testing (TLPT) at least every three years on the systems supporting critical functions. TLPT is a specific kind of red-team exercise inspired by the TIBER-EU framework, conducted by accredited testers under the supervision of the competent authority, and focused on simulating realistic adversaries against production systems with limited prior notice to the defenders.
When a financial entity conducts TLPT, the test scope can include the ICT third-party providers supporting critical functions. As a SaaS, this means you may be in scope of your customer's TLPT engagement. Typical implications:
What participation in customer TLPT looks like
- A small number of named individuals at your company (the "white team") are aware of the test; nobody else is.
- The accredited testers attempt realistic intrusion paths through your services to your customer's environment.
- You agree to specific rules of engagement (RoE) defining what is in/out of scope and how to handle accidental impact.
- You receive a partial debrief after the test concludes; the full report goes to your customer and competent authority.
- Findings against your environment may require remediation that you fund and prioritize on your own roadmap.
For most SaaS, TLPT participation is an annual or triennial event affecting only the largest customers. The contractual obligation to participate is in Article 30(3) item 11, the "support and participation in TLPT" clause. You can negotiate scope and timing, but you cannot negotiate the obligation away.
In addition to TLPT, DORA requires routine operational resilience testing under Article 25, which includes vulnerability assessments, network security assessments, gap analyses, physical security reviews, source code reviews, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing. These are conducted by the financial entity but rely on cooperation from ICT providers.
Step Five
SOC 2 + ISO 27001 + DORA: What Is Already Covered, What Is the Gap
DORA's expectations overlap with SOC 2 Type 2 and ISO 27001 in obvious places (security controls, incident handling, vendor management) and diverge in several specific areas (operational resilience testing, exit strategies, sub-contracting governance, register of information). Here is the practical comparison:
The practical implication is that having SOC 2 Type 2 and ISO 27001 means you have done most of the technical security work. You still need to: (1) build a documented exit strategy and runbook with annual test, (2) build the register of information that DORA Annex IV requires, (3) extend your sub-processor governance to flow down DORA-equivalent obligations, (4) prepare for TLPT participation by maintaining a relationship with red-team-capable testers, and (5) update your incident classification scheme to align with DORA's significance criteria.
Step Six
A Practical DORA Posture for SaaS
Rather than negotiating each customer contract from scratch, the efficient approach is to publish a DORA posture statement and use it as the baseline for negotiation. Here is the structure that has worked for clients:
- Trust portal DORA section. A dedicated page at /trust/dora that lists your standardized commitments: incident notification timing, SOC 2/ISO 27001 evidence, sub-processor list, exit strategy summary, register of information location, security testing schedule.
- Standard Article 30 contract addendum. A two-to-four page document that maps each Article 30 clause to your committed posture. Customers can attach this rather than rewriting their own from scratch.
- Annual operational resilience report. A short document published once per year summarizing your testing program, incidents, and exit-strategy validation. Sent to customers proactively.
- Pre-negotiated TLPT framework. A standard rules-of-engagement document for participating in customer TLPT, including timing windows, communications protocols, and remediation expectations. Customers cite it rather than each writing their own.
- Incident classification matrix aligned to DORA. Use DORA's significance criteria as the spine of your incident severity model, even for non-DORA customers. This ensures any DORA-customer notification triggers automatically.
- Registered EU representative. Although DORA does not strictly require an EU representative the way NIS2 does, having one in a member state simplifies dealings with multiple competent authorities and is increasingly expected by customers.
This approach turns DORA from a per-customer fire drill into a published platform commitment. Negotiations become "here is what we offer; what is the gap to what you need?" rather than "give us your 28-page amendment and we will respond in eight weeks." The deal cycle for new EU financial customers shrinks dramatically.
How Atlant Security Helps
DORA Posture Build For SaaS Selling To Financial Entities
Our DORA engagement starts with your existing SOC 2 / ISO 27001 program and builds the missing operational resilience layer. We produce the trust portal DORA section, the standard Article 30 addendum, the register of information, the exit strategy runbook, and the TLPT rules-of-engagement framework. Final deliverable is a complete, customer-defensible DORA posture you can attach to RFP responses and contract negotiations.
- Fixed pricing from $25,000 for SOC 2 Type 2 holders
- Senior consultants with EU regulatory background
- Includes review of two existing customer amendments
- EU representative network across 9 member states
- Pay after delivery and review
Frequently Asked
Questions From SaaS Selling To EU Banks
If we have SOC 2 Type 2, do we still need DORA work?
SOC 2 Type 2 is not enough by itself, but it is most of the way. The gap is operational resilience testing (TLPT, scenario-based tests, exit-strategy validation), the contractual machinery (Article 30 mandatory provisions in customer contracts), and the register of information. Most clients with SOC 2 Type 2 finish DORA-readiness work in 8 to 12 weeks rather than 4 to 6 months from a cold start.
Will the ESAs designate us as a "critical" provider?
Probably not. CTTP designations so far have targeted hyperscale cloud providers and major financial-data infrastructure firms. Most SaaS, even those serving multiple banks, fall well below the threshold. The more practical concern is whether your customers individually classify your services as supporting "critical or important functions," which triggers the stricter Article 30(3) clauses but not direct ESA oversight.
How long does an exit strategy runbook actually take to build?
For a SaaS with a single primary cloud and a clean data model, 2 to 3 weeks of focused work. For a complex multi-product, multi-region SaaS, 6 to 10 weeks. The runbook itself is short (10 to 25 pages); most of the time goes into building and testing the data export tooling and the migration playbook. Article 30(3) item 12 requires the runbook to be tested at least every two years, so build it as something you can actually rehearse.
What is the register of information and why does it matter?
The register of information is a structured database your customer maintains, listing every ICT contractual arrangement and certain attributes about each one. Implementing technical standards (RTS) under DORA define around 100 fields covering parties, services, locations, sub-contractors, and resilience metrics. As a SaaS, you contribute the data on your services. Your customers must report theirs to competent authorities annually. Having a reusable spreadsheet of your register fields saves dozens of hours per customer.
If I am US-headquartered with no EU presence, can I refuse to sign an Article 30 amendment?
You can refuse. Your customer will then be unable to keep using you under DORA, and they will switch to a competitor who accepts. The Article 30 obligations are imposed on the financial entity, not on you. The financial entity has to ensure the contract has those clauses; if you refuse, they cannot lawfully renew. We have one client who refused two amendments and lost two customers; both came back six months later when their replacements failed. Most US SaaS treat this as a one-time investment to access the EU financial market.
How does DORA interact with NIS2?
DORA is sector-specific (financial services); NIS2 is horizontal across 18 sectors. For financial entities, DORA applies as lex specialis - it overrides NIS2 where they conflict, and supplements it where it is silent. As a SaaS supplier, you can have one customer in scope of NIS2 only (e.g. an EU manufacturer) and another in scope of DORA (e.g. a German bank). The contracts will be similar but the regulatory regime they implement is different. We have a separate post on NIS2 for SaaS that covers the broader landscape.
DORA is not a compliance project; it is a capability. Companies that treat it as a one-time exercise to satisfy their largest EU customer end up redoing the work at every contract renewal. Companies that build a published DORA posture, refresh it annually, and use it as a sales enablement asset find that EU financial entities are some of their most efficient customers to onboard. The work front-loads in the first six months and pays back over multi-year contracts.
If you are reading this with a contract amendment open in another tab, the right next step is rarely to negotiate the amendment line by line. The right next step is to read it carefully, identify the three or four clauses that conflict with reality (not just preference), build a counter-proposal that demonstrates equivalent or better outcomes, and use it as the template for the next four amendments. The framework above is the version we use; it has held up across more than thirty client engagements.
Need help mapping a contract amendment to your existing program or building a DORA posture? Book a 30-minute consultation or email alexander@atlantsecurity.com directly.
Alexander Sverdlov
Founder of Atlant Security. Author of 2 information security books, cybersecurity speaker at the largest cybersecurity conferences in Asia and a United Nations conference panelist. Former Microsoft security consulting team member, external cybersecurity consultant at the Emirates Nuclear Energy Corporation.