sota.io
2026-05-05·14 min read·
Most SaaS providers serving European financial institutions focus their DORA reading on Art.31: the Critical Third-Party Provider designation, the lead overseer regime, the powers the ESAs can exercise. They conclude that because they are not on the CTPP list — which is short and populated by hyperscalers and major infrastructure providers — DORA does not really apply to them. This is the wrong conclusion. The CTPP regime in Arts.31–35 is the *oversight* mechanism for the largest systemic vendors. The *risk management* framework that applies to every ICT service provider used by a financial entity begins at Art.28 and reaches all the way to Art.30. That framework imposes mandatory contractual provisions on every agreement between a financial institution and its ICT vendors — regardless of CTPP status. If you sell SaaS to a European bank, insurer, payment institution, investment firm, or asset manager, your customer's legal team is going to present you with a set of DORA-mandated contract clauses at your next renewal. This guide explains exactly what those clauses require, why they exist, what your financial sector customers cannot waive, and what the 2026 enforcement environment means for vendors who are unprepared. ## The Structure: CTPP Oversight vs. Art.28-30 Risk Management DORA's ICT third-party risk framework has two distinct layers that are frequently confused: | Layer | Articles | Who It Applies To | Enforced By | |---|---|---|---| | **ICT third-party risk management** | Art.28–30 | ALL financial entities + ALL their ICT vendors | NCAs (BaFin, AFM, FCA-equiv., etc.) | | **CTPP oversight regime** | Art.31–35 | Designated Critical TPPs only | Joint ESA Oversight Committee | | **Sub-outsourcing chains** | Art.30(3) | ICT vendors with sub-providers | NCAs via financial entity | | **Exit strategies** | Art.28(7) | ALL financial entities | NCAs | The CTPP designation list, published by the Joint ESA Committee, covers fewer than 20 entities globally in its first iteration. The Art.28-30 risk management framework covers every ICT service provider used by every in-scope financial entity — which means tens of thousands of SaaS vendors, cloud tools, API providers, and infrastructure platforms. Your financial sector customers are in scope for Art.28-30. Through those articles, you are in scope for mandatory contractual provisions under Art.30 whether you want to be or not. ## Art.28: What Your Financial Customers Must Do Before Contracting Art.28 imposes pre-contract due diligence obligations on financial entities. Understanding what your customers are required to do helps explain why their DORA vendor questionnaires have become so detailed. ### Art.28(2): Risk Assessment Before Any ICT Contract Financial entities must assess whether an ICT third-party arrangement "is expected to support critical or important functions" before entering the contract. This is a formal risk categorisation exercise. Functions that support customer-facing financial services, core banking processes, regulatory reporting, or operational resilience are typically categorised as critical or important. The result of this assessment determines the intensity of oversight requirements. For vendors supporting critical or important functions, financial entities must: - Conduct full due diligence on the vendor's security posture, operational resilience, and financial stability - Assess the vendor's ability to meet DORA's incident notification requirements - Review the vendor's sub-outsourcing chain for concentration risk If your customer categorises your SaaS as supporting a critical or important function — which is common for core operational tools — you will face the full weight of Art.28-30. ### Art.28(3): Ongoing Monitoring Due diligence does not stop at contract signature. Art.28(3) requires financial entities to monitor their ICT service providers on an ongoing basis. In practice, this means: - Annual security questionnaire reviews - Review of audit reports (SOC 2 Type II, ISO 27001, ISAE 3402, or equivalent) - Assessment of any material changes to your service, infrastructure, or ownership - Incident tracking and root cause analysis review As a vendor, this translates to an expectation that you can produce fresh compliance evidence annually and respond to questionnaires within a defined SLA. Financial entities with tight internal compliance timelines will often specify questionnaire response windows of 10-15 business days in the vendor contract itself. ### Art.28(4): ICT Concentration Risk Art.28(4) requires financial entities to avoid ICT concentration risk — over-reliance on a small number of third-party providers, particularly where those providers are not subject to equivalent EU regulatory oversight. This has a direct and commercially significant implication for US-based SaaS providers: financial entities subject to ECB guidance and EBA concentration risk guidelines are increasingly being advised to diversify away from single-jurisdiction dependencies. The CLOUD Act creates a structural concentration risk that EU-native providers do not share: US law can compel US-incorporated cloud providers to produce data stored anywhere in the world, regardless of contractual data residency commitments. A bank's DORA concentration risk assessment that identifies a critical vendor as subject to CLOUD Act compulsion will flag this as a risk requiring mitigation. The mitigation is either contractual controls (which CLOUD Act renders partially ineffective) or vendor substitution with an EU-native alternative. ## Art.29: Responsibility Cannot Be Delegated Art.29 addresses a fundamental regulatory principle: financial entities cannot outsource their DORA obligations. The article explicitly states that "financial entities shall at all times remain fully responsible for compliance" with DORA requirements, even when functions are supported by ICT third-party providers. For you as a vendor, this shapes how your customer interprets their relationship with you. They are not delegating their DORA compliance to you. They are extending their risk management framework *through* you. Every audit right, every incident notification obligation, every contractual minimum provision in Art.30 is your customer managing their own regulatory exposure by ensuring that your operations meet the standards DORA requires of them. This is why DORA compliance clauses in vendor contracts are often non-negotiable from your customer's perspective. Their legal team is not adding them for commercial leverage — removing them would put the customer in violation of Art.28 and Art.29. ## Art.30: The Mandatory Contractual Provisions Art.30 is the article that will directly shape what your DORA-facing contracts look like. It specifies a minimum set of provisions that financial entities must include in every ICT service agreement with a third-party provider. ### Core Mandatory Provisions Under Art.30(2) **Full description of services:** The contract must clearly describe all ICT services being provided, including sub-outsourcing chains. Vague SaaS agreements that reference "cloud hosting" without specifying infrastructure providers will be flagged. **Locations of data processing:** The contract must specify where data is processed, stored, and backed up. Post-Brexit, EU-only financial entities are paying close attention to whether their vendors have UK or US data processing in their stack. **Provisions on data accessibility and recoverability:** Financial entities must be able to access and recover data at all times. This includes RPO and RTO commitments that are expressed in the contract, not just in a service level agreement that can be modified unilaterally. **Notice period for sub-outsourcing changes:** If you change your sub-providers (your cloud infrastructure provider, your database vendor, your CDN), the contract must specify a notice period that gives your customer time to reassess their concentration risk before the change takes effect. **Full cooperation in supervisory examinations:** Financial entities must be able to involve you in supervisory examinations by NCAs. This means providing regulators access to documentation, systems, or personnel relevant to the assessment. Financial entities cannot contractually shield vendors from this. **Exit rights and termination rights:** Contracts must include explicit exit strategies that allow financial entities to terminate the arrangement and migrate their data in a defined timeframe without operational disruption. ### Art.30(3): Sub-Outsourcing Chain Visibility Art.30(3) extends the contractual provisions framework to sub-outsourcing chains. If you use sub-providers for any part of your ICT service delivery — cloud infrastructure, database services, CDN, monitoring tools — your financial sector customers need visibility into those arrangements. Specifically: - You must identify all sub-providers that support the contracted service - You must apply equivalent contractual protections to your sub-providers that your financial customers apply to you - Any material changes to sub-outsourcing arrangements require prior notice to your financial customer In practice, this creates a compliance waterfall. Your customer's DORA obligations flow through your contract to your sub-providers. If you run on AWS, Azure, or GCP — which are US-incorporated and subject to CLOUD Act — you need to disclose this, and your customer needs to assess whether this creates concentration risk in their Art.28(4) review. ### Art.30(4): Provisions for Critical or Important Functions For ICT services supporting critical or important functions, Art.30(4) mandates additional provisions: **Full audit rights:** Financial entities must have the contractual right to inspect and audit the ICT service provider, either themselves or through a designated auditor. This is a hard legal requirement that cannot be waived. **Information security event notification:** The contract must specify notification obligations for information security events that could affect the financial entity's operations. Critically, Art.30(4)(b) requires these notifications to be provided "without undue delay" — which in regulatory practice means timelines consistent with DORA's own major incident reporting framework (4-hour initial classification, 72-hour intermediate report). **Service level agreement enforcement:** Where SLA breaches occur that could impair the financial entity's ability to meet its DORA obligations, the contract must provide for escalation and remediation processes. ## The Incident Notification SLA Problem The 4-hour incident notification obligation that you have probably heard associated with DORA applies to financial entities reporting to their NCA under Art.19. But the practical effect is that this obligation flows upstream to every vendor supporting critical or important functions. Here is why: a financial entity must classify an incident as "major" within a defined window and then notify its NCA within 4 hours of classification. To meet that deadline, it needs to know that an incident affecting its operations has occurred. If the incident originated in your SaaS platform, you are the first to know. Your customer cannot meet its Art.19 obligation without timely notification from you. Financial sector contracts are therefore increasingly requiring ICT vendors to: **Notify within 2 hours of incident detection** for any incident affecting the financial entity's operations, regardless of whether the incident meets the Art.18 "major incident" threshold at your end. The financial entity needs time to apply their own Art.18 classification before the Art.19 clock starts running. **Provide root cause analysis within 72 hours** of a confirmed incident, aligned with the Art.19 intermediate report timeline. **Supply final incident reports within 30 days**, mirroring Art.19's final report deadline. These contractual obligations are upstream contractual obligations that mirror your customers' regulatory obligations downstream. If your incident response process has no defined SLAs for customer notification, your financial sector customers will add them. ### Practical Minimum — What Your Incident Process Needs To satisfy DORA-aligned contractual notification obligations, your incident response process needs: ``` Incident Detection → Customer Notification ├── Severity P1 (operations impacted): ≤2 hours ├── Severity P2 (degraded performance): ≤4 hours ├── Severity P3 (minor issues): ≤24 hours └── Root Cause Analysis: ≤72 hours ``` The notification must include: incident description, affected services, estimated duration, remediation steps underway, and a named escalation contact. Financial sector contracts will often specify the exact information fields required in the notification. ## Geographic Requirements and Concentration Risk DORA Art.28(2) and the EBA Guidelines on ICT and security risk management both address geographic concentration risk in ICT third-party arrangements. For EU-incorporated financial entities, reliance on US-based SaaS infrastructure creates two compounding risks: **CLOUD Act cross-border data access:** The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) allows US law enforcement to compel US-incorporated providers to produce customer data stored anywhere in the world. This is not resolved by contractual data residency commitments. If your cloud infrastructure runs on AWS, Azure, GCP, or any US-incorporated cloud provider, your financial sector customers' data is theoretically accessible under US legal process. **Third-country transfer exposure under GDPR:** Financial institutions processing personal data are subject to both GDPR Chapter V restrictions on international transfers and DORA operational resilience requirements. Using a SaaS platform that routes data through US infrastructure creates dual regulatory exposure. EU-native SaaS platforms — running entirely on EU-incorporated infrastructure — eliminate the CLOUD Act exposure from your customer's concentration risk assessment. This is not a marketing claim; it is a structural difference in the legal risk profile of the vendor arrangement. ### What EU-Native Means Under DORA For DORA concentration risk assessment purposes, "EU-native" means: - Incorporated in an EU member state (not a US subsidiary with EU operations) - Hosting infrastructure contracted from EU-incorporated providers (not AWS Frankfurt, which is legally part of Amazon.com, Inc.) - Data processing subject exclusively to EU/EEA legal jurisdiction - No transfer mechanism reliance (no SCCs, BCRs, or adequacy decisions required) Platforms like [sota.io](https://sota.io) are incorporated and operate exclusively within EU legal jurisdiction, running on EU-incorporated infrastructure providers. For financial sector customers conducting DORA Art.28 concentration risk assessments, this removes an entire category of third-country transfer risk from the vendor assessment. ## The 2026 Enforcement Context DORA became applicable in January 2025. Q1 2026 was the first full regulatory year, and national competent authorities have been conducting initial supervisory reviews of financial entities' DORA implementation. BaFin in Germany, AFM in the Netherlands, AMF in France, and CBI in Ireland have all published their DORA supervisory priorities. Common findings in early reviews include: - Incomplete ICT third-party registers (Art.28(3) monitoring obligation) - Contracts without the full Art.30(2) mandatory provisions - Missing audit right clauses in vendor agreements - Incident notification procedures that do not meet the Art.30(4)(b) timeline For SaaS vendors, these findings translate directly into pressure. If your financial sector customer receives a supervisory finding related to their vendor contracts, the finding will roll into their remediation program — and their DORA programme management team will be contacting vendors with contract amendment requests. ## Your DORA-Readiness Checklist for Financial Sector Customers To be contract-ready for financial sector customers in 2026, your SaaS platform needs: **1. Art.30(2) contract compatibility:** - [ ] Full service description with infrastructure and sub-provider identification - [ ] Data location specificity (country, provider, data centre class) - [ ] RPO and RTO commitments contractually expressed - [ ] Sub-outsourcing change notice (minimum 30 days recommended) - [ ] Cooperation with supervisory examinations clause - [ ] Exit and data portability provisions **2. Audit and assessment readiness:** - [ ] SOC 2 Type II or ISO 27001 certification (or audit roadmap with timeline) - [ ] Security questionnaire response capability (CAIQ, SIG, or customer-specific) - [ ] Named security contact for audit coordination - [ ] Evidence package for virtual audit walkthroughs **3. Incident notification process:** - [ ] Defined customer notification SLAs (P1 ≤2h, P2 ≤4h) - [ ] Structured incident notification template matching Art.19 intermediate report fields - [ ] Root cause analysis process with 72-hour output - [ ] Escalation path documented and tested **4. Sub-provider transparency:** - [ ] Current SBOM or infrastructure stack disclosure - [ ] Mechanism for notifying customers of material sub-provider changes - [ ] Contractual flow-down for DORA obligations to your own sub-providers **5. Geographic and concentration risk posture:** - [ ] Clarity on legal jurisdiction of your entity and your infrastructure providers - [ ] Assessment of CLOUD Act exposure in your stack (if US-based infrastructure) - [ ] Data residency documentation that is legally accurate (not just marketing) --- The CTPP designation list is short. The Art.28-30 risk management framework is not. If you serve financial sector customers in Europe, DORA is already shaping their vendor contracts, their procurement processes, and their supervisory examination responses. Vendors who can satisfy these requirements with minimal friction — clear contracts, audit-ready documentation, fast incident notification — will win enterprise financial sector deals in 2026. Vendors who cannot will face procurement friction and contract renegotiations. EU-native deployment is one structural advantage that eliminates an entire category of DORA risk assessment from your customer's programme. But documentation, process, and contractual readiness are what convert that structural advantage into signed contracts.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing