sota.io
2026-05-05·13 min read·
The EU Data Act (Regulation 2023/2854) became fully applicable on 12 September 2025. Chapter V — Arts. 23–31 — is the one most data processing service providers have avoided reading carefully. It deals with switching: the right of your customers to move their data and workloads away from you to a competitor or to their own infrastructure. The obligations in Chapter V are not optional. They are not limited to large cloud providers. They apply to any legal entity offering *data processing services* — a term broad enough to capture IaaS, PaaS, SaaS, managed databases, analytics platforms, and most forms of cloud-adjacent infrastructure — when those services are offered to customers in the EU. What this means in practice: if you run a SaaS product or cloud platform serving European customers, you are required to have a portability API, a documented data export format, a maximum switching charge schedule that reaches zero by the end of 2027, and a 30-day transition assistance window. These are not aspirational standards. They are enforceable by national competent authorities with the power to impose fines under Art. 40. This guide explains what each obligation requires at the implementation level, what contract clauses to prepare for, and how EU-native deployment architecture affects your compliance surface. ## What Is a Data Processing Service Under the Data Act? Art. 2(8) of the Data Act defines a data processing service as "a digital service other than an electronic communications service, provided to a customer, which enables on-demand network access to a shared pool of configurable, scalable and elastic computing resources of a centralised, distributed or highly distributed nature." The Recitals are explicit: IaaS, PaaS, and SaaS are all in scope. So are managed database services, edge computing, analytics platforms, and developer tooling that runs as a hosted service. The key threshold is whether you enable customers to process data using your infrastructure. Exemptions are narrow: - Microenterprises (fewer than 10 employees, annual turnover/balance sheet ≤ €2 million) get full exemption - Small enterprises (< 50 employees, ≤ €10 million) get partial exemption on some switching charge provisions - Pure data brokerage services that do not provide processing infrastructure are out of scope - Electronic communications services (internet access providers, email) follow the ePrivacy framework instead If you are an EU-facing SaaS or PaaS product with more than 50 employees or €10 million in annual revenue, Chapter V applies to you in full. ## Chapter V At a Glance | Article | Obligation | Deadline | |---|---|---| | **Art. 23** | Customer right to switch; no contractual prohibition | Applicable from 12 Sep 2025 | | **Art. 24** | Mandatory contractual switching provisions | 12 Sep 2025 | | **Art. 25** | Technical switching assistance obligations (30-day window) | 12 Sep 2025 | | **Art. 26** | Maximum switching charges (capped then zero) | Zero by 31 Dec 2027 | | **Art. 27** | Technical requirements: open interfaces, documented API | 12 Sep 2025 | | **Art. 28** | Functional equivalence during switching period | 12 Sep 2025 | | **Art. 29** | Data preservation and deletion obligations | 12 Sep 2025 | | **Art. 30** | Transitional period for existing contracts | 3.5 years from Sep 2025 | | **Art. 31** | Access requests from public bodies | 12 Sep 2025 | ## Art. 23: The Right to Switch Art. 23 establishes the customer right to switch to a different data processing service provider or to on-premise infrastructure. The right cannot be waived contractually. Three concrete implications for your terms of service: **1. No contractual lock-in clauses.** Any clause that prohibits, restricts, or makes economically unviable a customer's decision to switch is void under Art. 23(2). This includes minimum-term penalties that would result in charges significantly exceeding your actual cost of providing the switching assistance, automatic renewal clauses with exit charges, and most-favoured-nation clauses that tie pricing to staying with you. **2. No technical lock-in through proprietary data formats.** Art. 23 read together with Art. 27 means you cannot deliberately store customer data in formats that require your proprietary tooling to export. This does not mean you cannot use internal storage formats — it means you must offer export in a format the customer can use elsewhere. **3. No adverse treatment of switching customers.** Degraded service quality, reduced support responsiveness, or withheld access to features in the period following notice of switching is a violation of the functional equivalence obligation in Art. 28. ## Art. 24: Mandatory Contract Clauses Art. 24 requires that contracts for data processing services include provisions covering: - **Complete description of data categories** available for export. A clause that says "all customer data" is probably insufficient; regulators expect itemised lists of data types stored, processed, and generated. - **Export formats and technical means** for switching. This must specify the format (JSON, CSV, Parquet, SQL dump, or equivalent) and the technical channel (API endpoint, SFTP, object storage export). - **Data retention periods** applicable before and after contract termination. - **Switching assistance obligations** including the minimum 30-day window and what assistance looks like (documentation, dedicated support channel, export tooling). - **Switching charges** schedule including the zero-charge commitment required by Art. 26. From an engineering standpoint, the contract clause requirement creates a feedback loop into your product: if you cannot describe the export formats in the contract because they are ad-hoc or undocumented, you do not have a compliant switching implementation. ## Art. 25: The 30-Day Switching Assistance Window Art. 25 requires you to provide active switching assistance for a minimum of 30 calendar days following the customer's switch notice. During this period: - All customer data must remain accessible and exportable - You must provide documentation sufficient for the customer or their new provider to reconstruct the service environment - Support for export-related queries must be available - You must not degrade service quality, API rate limits, or data access The 30-day window begins when the customer provides written switch notice, not when they complete the switch. If the customer's new provider needs longer to complete data ingestion, you are not required to extend the window beyond 30 days — but you cannot terminate data access before the 30 days expire. **What this means for your architecture:** Your export pipelines need to be able to run continuously over a 30-day window, not just as one-time snapshots. If your export is a single-shot job that produces a large file, customers with large data volumes will struggle. Consider: - Incremental export APIs that allow the customer to pull data in chunks - Checksums and manifest files so the customer can verify completeness - Change data capture (CDC) streams so new data written during the switching period is also captured - Version-pinned export schemas so the customer's ingestion pipeline does not break if your schema evolves during the switching window ## Art. 26: Switching Charges — The Zero-Charge Timeline Art. 26 establishes a two-phase switching charge restriction: **Phase 1 (Sep 2025 – Dec 2027):** Switching charges must not exceed the actual cost of providing switching assistance. You can charge for engineering time spent on export tooling, dedicated support, data transfer costs, and documentation preparation — but not for the "economic inconvenience" of losing the customer. **Phase 2 (from 1 January 2028):** All switching charges are zero. You may not charge anything for enabling a customer to export their data and leave your platform. The practical implication is that switching assistance must be a zero-marginal-cost operation from a product perspective by January 2028. If your export tooling requires significant manual engineering work per customer, you have a cost problem brewing. **Design for zero cost:** Build export as a self-service workflow. The customer should be able to initiate, monitor, and complete a full data export without opening a support ticket. Standard patterns: ```text POST /api/v1/exports → initiate export job GET /api/v1/exports/:id → check status + progress GET /api/v1/exports/:id/manifest → list of exported objects GET /api/v1/exports/:id/download → download or get presigned URLs ``` The export endpoint should accept a format parameter (`format=json`, `format=csv`, `format=parquet`) and a scope parameter (all data, or data categories by type). Rate limiting on export endpoints is permitted but must not make the 30-day switching window practically unworkable. ## Art. 27: Open Interface Requirements Art. 27 is the most technically specific provision in Chapter V. It requires data processing service providers to: **Make open interfaces available.** "Open interface" under the Data Act means an interface documented with sufficient precision that a technically competent party can use it without access to your internal systems or proprietary SDKs. This is closer to an "open specification" than "open source." **Publish technical documentation.** The documentation must cover: - Authentication mechanism for export APIs - List of data categories accessible via the API - Data format specifications (field names, types, encoding) - Rate limits and throughput constraints - Error codes and retry semantics **Register open interfaces with the Commission.** The European Commission is establishing a registry of open interfaces. Providers must register their portability API specifications. The registry format and registration process was under development as of Q1 2026; expect ENISA or EUCS to publish guidance. **Interoperability standards where available.** Where the Commission has published delegated acts specifying mandatory data format standards for your sector, you must implement those formats. As of mid-2026, no sector-specific standards have been published for generic SaaS, but standards for healthcare, financial data, and smart grid data are in development. For most SaaS providers, Art. 27 compliance means: document your export API at the same quality level as your core product API, make the documentation publicly accessible (not behind a login wall), and ensure the API works without access to your internal admin tooling. ## Art. 28: Functional Equivalence Art. 28 requires that the data processing service maintains the same level of functionality, quality, and security during the switching period as it provides under normal operation. This provision exists because some providers historically degraded service for switching customers — slowing API response times, reducing storage quotas, or deprioritising support tickets flagged as "churning customer." Enforcement of Art. 28 is complaint-driven. National competent authorities can investigate if a customer reports degradation after providing switch notice. The key compliance requirement is that you should not have any internal system flags that modify service delivery based on churn/switching status. If your billing system, CRM, or infrastructure automation has a concept of "customer is leaving" that triggers any automated action beyond administrative offboarding tasks, review whether that action could be construed as degraded service. ## Art. 29: Data Preservation and Deletion Art. 29 creates a dual obligation: **Preservation during switching:** Customer data must be preserved for the full switching assistance period (at least 30 days from notice). You may not delete or archive data to slower storage tiers during the switching window. **Deletion after the switching period:** After the switching period ends, you must delete customer data in accordance with your contract and applicable GDPR obligations. You cannot retain customer data "for backup purposes" beyond the contractual retention period without a separate legal basis. The GDPR angle here matters: if you have GDPR Art. 17 erasure obligations, those survive the Data Act switching period. The switching period does not create a data retention right for you — it creates a data access right for the customer. **Architecture implication:** Do not use your backup system as your switching-period data preservation mechanism unless your backup system can produce customer-accessible exports. If your disaster recovery infrastructure holds the only copy of customer data during the switching period, you need a way to export from it. ## Implementation Checklist **API and export infrastructure (Art. 25, 27):** - [ ] Self-service export API with job initiation, status polling, and download endpoints - [ ] Export supports at least one machine-readable, non-proprietary format (JSON, CSV, Parquet, or sector standard) - [ ] Export API is documented publicly with field definitions, types, and examples - [ ] Incremental export supported for customers with large data volumes (> 10 GB) - [ ] Export manifest file lists all exported objects with checksums - [ ] Change data capture available for data written during the switching period **Contract and legal (Art. 23, 24):** - [ ] Terms of service contain no clauses that prohibit or economically penalise switching - [ ] Contract includes itemised list of data categories available for export - [ ] Contract specifies export format and technical channel - [ ] Switching charge schedule included with zero-charge commitment by end of 2027 - [ ] 30-day switching assistance window documented **Operational processes (Art. 25, 28, 29):** - [ ] Internal systems have no automated degradation triggered by switching/churn flags - [ ] Data is preserved in primary storage for the full 30-day switching window - [ ] Post-switching deletion process is documented and auditable - [ ] Support SLA during switching period is documented and equivalent to normal operation **Transparency (Art. 27):** - [ ] Open interface documentation is publicly accessible without login - [ ] Documentation includes authentication method, data categories, formats, rate limits, error codes - [ ] Process established to register interfaces with Commission registry when operational ## The CLOUD Act Problem During Switching One dimension of switching compliance that intersects with GDPR and data sovereignty is where your export infrastructure runs. If your data processing service runs on US-cloud infrastructure (AWS, Azure, GCP), the export data — potentially including all of your customer's production data — is accessible to US law enforcement under the CLOUD Act during the switching window. For B2B customers in regulated industries (financial services, healthcare, critical infrastructure), this creates a compliance issue: Art. 25 requires that data remain accessible during the switching period, but GDPR Art. 44 requires that the data transfer framework for the customer's new provider be in place before export is routed to them. If you are migrating a customer from a US-hosted SaaS to an EU-native alternative, the export routing matters: the export data should never traverse US infrastructure if the customer's new home is entirely EU. This is not a hypothetical concern — it is the same routing problem that affects all cross-border personal data exports under Schrems II. EU-native SaaS providers (running on infrastructure with no US parent or ownership chain) eliminate this concern by design: the export job runs on EU infrastructure, the presigned download URLs are served from EU object storage, and there is no CLOUD Act hook in the data path. ## Enforcement Timeline The Data Act became applicable September 2025. The enforcement environment in early 2026 remains in its initial phase: - National competent authorities have been designated but are still establishing enforcement processes - The Commission is finalising delegated acts for sector-specific data format standards - The open interface registry is not yet fully operational - Most enforcement actions to date have been informal investigations triggered by customer complaints The practical window for remediating switching API gaps is closing. Customers in regulated industries are beginning to include Data Act Art. 24 contract clause requirements in procurement documentation. Providers that cannot provide export API documentation or switching charge schedules at contract signing are increasingly losing deals in enterprise sales cycles. ## What Changes at sota.io For developers hosting applications on EU-native PaaS infrastructure, the Data Act creates indirect obligations: if your application itself is a data processing service, *your* switching API must comply with Chapter V regardless of where you host it. Your choice of hosting does not affect your Art. 27 open interface obligations. What EU-native hosting does affect: - **Geographic concentration risk:** DORA Art. 28 and the Data Act's approach to interoperability both favour multi-provider resilience. Customers in regulated sectors are increasingly requiring that vendors can demonstrate ability to switch providers themselves. - **CLOUD Act-free export path:** As described above, EU-native infrastructure ensures export data never enters a US-law-enforcement-accessible environment. - **Data residency during transition:** Art. 29 preservation obligations are easier to audit when your retention infrastructure is in-scope for EU data protection law. Running on a platform with no US parent means the switching assistance you offer your customers does not create a secondary CLOUD Act exposure vector for their data. ## Summary Chapter V of the EU Data Act is a concrete engineering mandate with a fixed timeline. By December 2027, switching from your platform must be free. By September 2025 (already passed), it must be technically possible without your active involvement. If your export tooling requires manual engineering work per customer, you have a cost and compliance gap. The minimum viable implementation: a self-service export API, publicly documented in a format that lets the customer's new provider build an ingest connector without your help, with a zero-charge switching schedule in your contract, and no automated service degradation on churn. The complete implementation adds incremental export, CDC streams, change data access during the 30-day window, EU-only data routing for the export path, and registration with the Commission's open interface registry when it becomes operational. The providers that treat switching compliance as a product feature rather than a legal burden will find it creates competitive advantage: customers in procurement cycles that include Data Act due diligence will select providers with documented switching APIs over those that require a support ticket to begin an export.

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