Your SaaS terms contain one sentence: “After termination of the agreement, the Customer’s data will be deleted within 30 days”. It sounds safe. As of 12 September 2025, it is unlawful — and that is the least of your problems.
Chapter VI of Regulation (EU) 2023/2854 (Data Act) imposes a multi-stage switching procedure on providers of cloud-based data processing services and SaaS. The maximum notice period is 2 months. A mandatory transitional period with full service continuity — up to 30 days. At least 30 days to download data after the migration is complete. In total: more than two months after termination of the agreement during which you must maintain access to the customer’s data. Yet a typical data processing agreement provides for data to be deleted “no later than within 30 days”. These documents contradict each other.
In this article, I will show where the SaaS terms templates available on the market break down under the Data Act, which deadlines you need to include in your terms, and why the greatest risk lies not in the terms themselves, but at the intersection of documents — in a single sentence of the precedence clause in the data processing agreement.
Key concepts before we proceed
Before moving on to the specifics, it is worth clarifying several terms used in the Regulation that will recur throughout this article.
| Concept | What it means under the Data Act |
|---|---|
| Data processing service | A cloud or SaaS service in which the provider stores and processes customer data on its own infrastructure — the typical subscription model |
| Switching | A procedure in which a customer transfers data and digital assets from one provider to another or to its own infrastructure |
| Transitional period | The period following notice of termination during which the provider continues to provide the service with full continuity, enabling the customer to migrate |
| Exportable data | Data entered by the customer into the application that is subject to export — excluding reference data and the provider’s internal data |
| Digital assets | Elements in digital form, including applications that the customer is entitled to use independently of its agreement with a particular provider |
| Unfairness test (Article 13) | A mechanism for assessing whether a unilaterally imposed contractual term grossly deviates from good commercial practice — if it does, it is not binding on the other party |
Two portability mechanisms that SaaS terms regularly confuse: Article 20 GDPR is a right held by a natural person against a personal data controller. Chapter VI of the Data Act is a right held by a business customer against a data processing service provider. A different entitled party, a different legal basis, and different provider obligations. If your terms contain a single “data portability” clause referring to both provisions jointly, your legal framework is defective.
Timeline of the switching procedure under the Data Act
SaaS terms templates available on the market either contain no Data Act provisions at all or include a single sentence about exporting data in a machine-readable format. That does not cover even half of the requirements under Article 25.
Below is the full timeline that your terms must reflect as of 12 September 2025:
| Stage | Deadline | What happens |
|---|---|---|
| Customer request | Day 0 | The customer submits a switching request in documentary form. The request should specify its purpose: migration to another provider, transfer to the customer’s own infrastructure, or deletion of the data only |
| Notice period | Max. 2 months | The customer may specify a shorter period. The agreement remains in force on its existing terms |
| Transitional period | Max. 30 calendar days | The provider ensures full continuity of the service, assists with the migration, and provides information about known risks to continuity. The customer is entitled to a one-time extension for a period it considers more appropriate |
| Technical infeasibility clause | 14 working days to give notice + an alternative period of up to 7 months | If the 30-day transitional period is technically infeasible, the provider must notify the customer within 14 working days and propose an alternative |
| Data retrieval period | Min. 30 days after completion of the migration | The service is no longer provided, but the provider ensures the availability and security of exportable data |
| Notice before deletion | Min. 7 days (contractual arrangement) | The provider informs the customer of its intention to delete the data |
| Termination of the agreement | After completion of the procedure | The agreement is deemed terminated; the provider informs the customer |
Note the arithmetic: even in the shortest scenario (the customer specifies a shorter notice period + a 30-day transitional period + 30 days to retrieve the data), the procedure takes considerably longer than the 30 days you specify in the data processing agreement as the deadline for data deletion.
Who must implement this? Every SaaS and cloud service provider operating in the B2B model that offers a product commercially through a service catalogue. The exception under Article 31 applies only to non-production versions made available for testing for a limited period. If the customer enters real data during your trial, the exception does not apply and the procedure also covers the free-of-charge agreement.
Recital 98 of the Data Act exempts services developed to order for an individual customer from certain obligations. However, a typical SaaS product sold through a website does not qualify for this exception.
Five ways SaaS terms templates break down under the Data Act
1. One sentence about data deletion instead of a switching procedure
Typical SaaS terms: “After termination of the agreement, the Customer’s data will be deleted within 30 days”. Article 25(2) of the Data Act requires a multi-stage procedure with specific deadlines, information obligations, and the customer’s right to extend the transitional period. A single sentence about deletion does not satisfy any of these requirements.
2. No catalogue of exportable data or exclusions
Without a catalogue, the customer may demand the export of the provider’s licensed reference data — sanctions lists, registers, and dictionaries. Specify what is subject to export (data entered by the customer), in which formats (XLSX/CSV, JSON for APIs, PDF for reports), and what is excluded (the application’s internal data and reference databases licensed by the provider).
3. No information layer outside the terms
Articles 24 and 26 of the Data Act require the public disclosure of information that cannot be contained solely in the terms: a register of the structures and formats of exportable data, a description of migration procedures and known technical limitations, and information about the jurisdiction governing the IT infrastructure and measures preventing third-country authorities from accessing non-personal data stored in the EU. This should be provided on a separate page or in a document referenced by the terms.
4. Trial period without a switching procedure
If the customer enters real data during the trial, the exception under Article 31 does not apply. And trial data is covered neither by the data processing agreement nor by the privacy policy — leaving it without a specified deletion deadline. Extend the procedure to the free-of-charge agreement, with separate, shorter deadlines.
5. No rule for incomplete requests
The customer submits a switching request but does not specify the purpose of the migration. Without a rule governing incomplete requests, an incomplete submission prevents all deadlines from starting to run — the provider does not know whether to export or delete the data. Include a presumption: if the customer does not specify the purpose within X days, the request will be treated as a request to delete the data.
The precedence clause in the data processing agreement — a hidden flaw in the entire procedure
This is where SaaS terms contain their greatest flaw — one their authors are unaware of.
A typical personal data processing agreement contains the following clause: “In the event of a conflict between this agreement and the terms, this data processing agreement shall prevail in matters concerning the processing of personal data”.
It sounds reasonable. The problem is that, in a SaaS tool processing almost exclusively personal data (as is the case with most B2B products — from CRM and HR to AML/KYC), this clause does three things at once:
| What the precedence clause does | Effect |
|---|---|
| Replaces the Data Act procedure in the terms with the 30-day deletion deadline in the data processing agreement | The entire multi-stage switching procedure becomes ineffective — in a dispute, the shorter deadline in the data processing agreement prevails |
| Takes claims outside the financial cap on liability | The terms contain a financial cap. The data processing agreement usually does not. The precedence clause means that all claims concerning personal data fall outside the cap |
| Creates two conflicting audit regimes | Terms: an audit once every 12 months, at the customer’s expense, with 30 days’ prior notice. Data processing agreement: the right to conduct an inspection at any time, free of charge if ordered by the supervisory authority |
What should you do about it? You have two options:
- Narrow the precedence clause to substantive processing matters (purposes, scope, and categories of data), expressly excluding liability for damages and service termination deadlines
- Align both documents in terms of the number of days and include an express reference in the data processing agreement to the Data Act section of the terms
Neither option is difficult. But neither will happen by itself.
Switching charges — phase-out schedule
The schedule for phasing out switching charges directly affects the SaaS provider’s business model:
| Period | Rule |
|---|---|
| 12.09.2025 – 12.01.2027 | The provider may charge reduced switching fees, but they may not exceed the costs actually incurred by the provider |
| From 12.01.2027 | A complete ban on any charges for the switching procedure. The ban also covers migration and testing tools |
| Multi-cloud (egress) | Charges for outbound data traffic when using the services of two providers in parallel remain permissible — up to the amount of the costs actually incurred |
This means that, from January 2027, the provider may not pass any portion of the migration costs on to the departing customer. The export feature, maintaining the environment during the transitional period, and testing tools at the new provider — all of these are the provider’s responsibility.
The unfairness test under Article 13 — why your limitation of liability may not work
Article 13 of the Data Act introduces a test for the unfairness of contractual terms between businesses. This is not about the relationship with a consumer — it concerns B2B relationships.
The mechanism works as follows:
- A unilaterally imposed term (and SaaS terms are, by definition, imposed unilaterally) is subject to assessment
- If it grossly deviates from good commercial practice and is contrary to good faith — it is not binding on the other party
- The burden of proving that the term was not unilaterally imposed rests with the provider
Article 13(4) contains a list of terms that are always unfair. These include: excluding or limiting the liability of the party that imposed the term for intentional acts or gross negligence.
This has direct implications for the limitation of liability clause in SaaS terms. The standard sentence “the provider’s liability is limited to the amount of X” may prove ineffective insofar as it covers damage caused intentionally or through gross negligence.
Hence the recommendation: a two-track limitation of liability — generally limited to intentional fault, and in matters related to making data available, also to gross negligence. This is consistent with both Article 13 of the Data Act and Article 473 § 2 of the Polish Civil Code, which prohibits the exclusion of liability for intentionally caused damage.
As of today, there is no case law from Polish courts or decisions by the President of UOKiK applying Article 13 of the Data Act to a specific contractual term. But the absence of case law does not mean the absence of risk — it means the absence of predictability.
Where SaaS documents say something different from the system
The most serious defects in SaaS terms are not found in the terms themselves. They lie at the intersections between documents — where the security appendix promises something the system does not do.
| Statement in the documents | Actual situation | Risk |
|---|---|---|
| “Centralised event logging and logging of every access to databases” | The system stores only timestamps for the creation and modification of records, without a user activity log | The lack of logs makes it impossible to determine the scope of an incident — in decision ZSOŚS.421.25.2019, the Polish Data Protection Authority identified the lack of traceability as a security risk and imposed a fine of PLN 50,000 |
| “Centralised identity management, including SSO and MFA support” | MFA is not enabled for application users — the description refers to a capability, not an implemented security measure | The reader interprets the document as a statement that it has been implemented |
| “RPO/RTO parameters compliant with the contractual SLA” | The terms contain no RPO/RTO parameters | A reference to something that does not exist |
| “Permanent deletion of data on request” | The application marks records as deleted (soft deletion); there is no process for permanently purging the database | The promise of permanent deletion and the statement that requests under Article 17 GDPR are supported are false |
| “Data in backups is deleted in accordance with the standard retention cycle” | The retention cycle is not defined | Open-ended storage period — a breach of Article 5(1)(e) GDPR (storage limitation) |
Ask the application developer each of these questions before signing the documents. Not after.
SLA — three pitfalls that change the service level
Support hours vs. 24/7
An SLA of 98% calculated only during working hours from 8 a.m. to 6 p.m. on business days represents a completely different service level from the same metric calculated around the clock. Night-time and weekend outages do not reduce the metric at all. Decide how it should be calculated and close the arithmetic gap with one sentence: periods excluded from downtime do not reduce the total number of hours used as the basis for calculating the metric.
For comparison, the Microsoft Power Platform documentation states that 99.9% availability corresponds to approximately 43 minutes of downtime per month, while 99.95% corresponds to approximately 21 minutes. But these figures are meaningful only when downtime and the measurement method are clearly defined.
Definition of downtime without exclusions
If you do not define downtime negatively (what downtime is not), then reduced performance, longer processing times, an error in a single feature — or even an incorrect result generated by an AI model — become an SLA breach. A model hallucination becomes grounds for a service credit. Exclude this expressly.
Service credit after termination of the agreement
The downtime occurred in the final month of the agreement. There is no subsequent billing period to which a discount can be applied. The service credit — formally the customer’s exclusive remedy — does not work. Add a mechanism: a reduction in the fee for the final billing period or a partial refund within 14 days after the claim is approved.
AML and AI layers — additional obligations your terms do not address
A SaaS tool is not an archive
If you are building a tool in which an obliged entity (a bank, fintech company, accounting firm, or real estate agent) verifies counterparties for AML purposes, remember Article 49 of the Polish AML Act. The obliged entity has a 5-year record retention obligation. This obligation remains with the customer, not the tool provider.
But the customer assumes that the records documenting the performance of its statutory obligations are stored safely in the application. The provider assumes that the customer downloads them on an ongoing basis. This mismatch comes to light during an inspection by an authority or when the account is closed — at the worst possible time.
What to include in the terms: three sentences at the beginning that define the nature of the application — an operational tool, not an archive. An obligation for the customer to download results on an ongoing basis. A statement that backups are not an archiving service. In a dispute, these three sentences do more than the entire limitation of liability clause because they eliminate the source of the claim instead of limiting it.
Language model providers classify your queries
If your SaaS product uses a large language model (LLM), check the provider’s terms. By default, OpenAI retains API data for up to 30 days to detect abuse. Content flagged as suspicious may be reviewed by authorised personnel. Disabling this feature (zero data retention) may be available only to customers with a particular contractual status.
This constitutes personal data processing if the prompts contain such data — and in an AML/KYC tool, they almost always do. Decide which document should disclose this: the subprocessor list, data processing agreement, or confidentiality clause.
AI Act — a date to remember
The AI Act obligations for high-risk systems listed in Annex III and the transparency obligations under Article 50 apply from 2 August 2026. Risk scoring of a counterparty that is a legal person does not, as a rule, fall literally within Annex III, point 5(b) (which concerns the assessment of the creditworthiness of natural persons). But if your tool assesses natural persons and the result materially affects a financial decision, classification as a high-risk system is justified. The full text of the AI Act requires an assessment that a system does not qualify to be documented, not merely declared.
Access management — a deadline that will not withstand scrutiny
A deadline of “without undue delay, no later than within 21 days” for revoking a former customer employee’s access is indefensible under Article 32 GDPR in a tool that processes data concerning suspected criminal offences.
Choose one access management model and shorten the deadline:
| Model | How it works | Access revocation deadline |
|---|---|---|
| Customer administrator | The customer manages user accounts itself through the administration panel | Immediately — responsibility lies with the customer |
| Managed by the provider | The customer submits a request and the provider carries it out | Hours or business days — not weeks |
Separate the deadline for revoking a former user’s access from the deadline for blocking an account after termination of the agreement. These are two different situations with different levels of risk.
Penalties — what we know and what we do not yet know
Article 37(1) of the Data Act requires each Member State to designate at least one competent authority. The draft Polish implementing act (Sejm paper no. 3266) provides for the President of UKE to be designated as the main authority and for administrative fines to be introduced.
As of the publication date of this article, the adoption of the Polish implementing act has not been confirmed. This means that:
- There is no national authority enforcing Chapter VI of the Data Act
- There is no national catalogue of penalties
- The Regulation itself applies directly — providers’ obligations apply regardless of the status of national legislation
The absence of national penalties does not mean the absence of risk. An unfair contractual term within the meaning of Article 13 of the Data Act is not binding on the other party — the risk that an entire limitation of liability clause will prove ineffective in a dispute exists regardless of whether an authority imposes a fine.
The scale of the issue — more than half of EU companies use SaaS
According to Eurostat data for 2025, 52.74% of EU enterprises used paid cloud services. Of those, 96.44% purchased at least one SaaS service. This means that the obligations under Chapter VI of the Data Act apply to providers serving the vast majority of the European B2B market.
The European Commission has developed non-binding Standard Contractual Clauses (SCCs) for cloud computing contracts, covering three groups: SCC Switching & Exit, SCC Termination, and SCC Security & Business Continuity. They can serve as a starting point when drafting clauses for your terms, but they do not replace the obligations arising from the Regulation.
Checklist — twelve questions for your SaaS terms
Before sending your document package to the customer, go through this list:
| No. | Question | Where to find the answer |
|---|---|---|
| 1 | Do the terms contain a separate section on switching with a full timeline (request → notice → transitional period → data retrieval → deletion)? | Terms — agreement termination section |
| 2 | Do the data processing agreement and the terms specify consistent data deletion deadlines? | Comparison of both documents |
| 3 | Is the precedence clause in the data processing agreement limited to substantive processing matters? | Data processing agreement — final provisions |
| 4 | Is there a catalogue of exportable data and a catalogue of exclusions? | Appendix to the terms |
| 5 | Is information about formats, structures, and the jurisdiction of the infrastructure publicly available? | Provider’s website |
| 6 | Is the trial period covered by the switching procedure and the data processing agreement? | Terms + data processing agreement |
| 7 | Does the SLA define downtime both positively and negatively (including the exclusion of AI errors)? | SLA appendix |
| 8 | Does the service credit work after termination of the agreement? | SLA appendix |
| 9 | Is the deadline for revoking a former user’s access measured in hours/days rather than weeks? | Terms or security appendix |
| 10 | Do the security statements (logs, MFA, RPO/RTO, backup retention, deletion) reflect the system’s actual architecture? | Comparison of the security appendix with the technical documentation |
| 11 | Do the terms define the nature of the application (operational tool vs. archive)? | Terms — general provisions |
| 12 | Is the language model provider disclosed in the subprocessor list, together with information about prompt retention? | Subprocessor list |
How we can help your company put its SaaS documents in order
Adapting SaaS terms to the Data Act is not a matter of revising a few sentences. It is a change that requires comparing the documents with the product architecture — and making decisions that go beyond the wording of the agreement itself.
We support SaaS providers and technology companies in three ways:
- Compliance audit — review of the terms against Chapter VI of the Data Act, comparison with the data processing agreement, and a list of inconsistencies to be corrected
- Redrafting the contractual framework — switching section, catalogue of exportable data, SLA, personal data role map, and alignment of the terms with the data processing agreement
- Complete document package — the entire set drafted from scratch, including the information layer published outside the agreement, a list of questions for the application developer, and a consistency check before the documents are sent to customers
We combine IT law, data protection, and contract law in a single model — instead of splitting the work into separate areas. We work with real-world scenarios: how data export works in your product, what your AI model does with prompts, where backups are stored, and who is responsible for them.
SaaS terms after the Data Act — three things to do this week
Chapter VI of the Data Act has applied since 12 September 2025. Your SaaS terms almost certainly do not comply with it — and the problem is not one sentence about data deletion, but the entire framework for exiting the agreement, the intersections between documents, and the discrepancies between statements and the system architecture.
Three things to do now:
- Open your terms and find the section on the consequences of terminating the agreement. If it consists of one sentence, you are non-compliant
- Compare the data deletion deadline in the data processing agreement with the timeline of the switching procedure in the terms. If they conflict, the precedence clause in the data processing agreement will render your entire procedure ineffective
- Ask the application developer whether the system does what the security appendices promise — logging, MFA, permanent deletion, and a backup retention cycle
If you need support reviewing your documents, redrafting the switching procedure, or comparing the terms with the product’s actual architecture — contact us.
Frequently asked questions
Does the Data Act apply to me if I am a small SaaS provider rather than a hyperscaler? Yes. Chapter VI of the Data Act applies to data processing service providers regardless of their size if they offer the service commercially. The exception in Recital 98 applies only to services developed to order for an individual customer — a typical SaaS product sold through a catalogue does not qualify.
My SaaS terms were drafted two years ago — where should I start to check whether they comply with the Data Act? Open the agreement termination section and check whether it contains a separate switching section with a full timeline: customer request, notice period (max. 2 months), transitional period (max. 30 days), data retrieval period (min. 30 days), and notice before deletion. If you have one sentence about deleting data within 30 days, you are non-compliant. Then compare that deadline with the deadline in the data processing agreement and check the precedence clause.
Do I have to provide the customer with a free export now, or only from January 2027? Until 12 January 2027, you may charge reduced switching fees, but they may not exceed the costs actually incurred. From 12 January 2027, a complete ban applies to charges for the switching procedure — including migration and testing tools. Egress charges in a multi-cloud model remain permissible up to the amount of the costs incurred.
My trial is free — does the switching procedure apply to me? If the customer enters real data during the trial, the exception under Article 31 of the Data Act (concerning non-production versions made available for testing for a limited period) does not apply. The switching procedure also covers a free-of-charge agreement. Introduce the concept of a trial period into the data processing agreement and privacy policy, with separate, shorter deadlines.
How long must I retain the customer’s data after termination of the agreement? According to the Data Act timeline: for the transitional period (max. 30 days with service continuity) plus at least 30 days for data retrieval after completion of the migration. In total — considerably longer than the 30 days you specify in the data processing agreement. If your customer is an obliged entity under the Polish AML Act, remember that the 5-year record retention obligation under Article 49 of the AML Act remains with the customer — your application does not transfer that obligation to you.
Why is the standard sentence giving precedence to the data processing agreement risky? Because, in a SaaS tool processing mainly personal data, the precedence clause takes almost all claims outside the financial cap on liability contained in the terms (the data processing agreement usually contains no financial cap) and replaces the multi-stage Data Act procedure with the shorter data deletion deadline in the appendix to the data processing agreement. Narrow the clause to substantive processing matters or align the deadlines in both documents.
