{"id":5264,"date":"2026-11-13T13:03:41","date_gmt":"2026-11-13T13:03:41","guid":{"rendered":"https:\/\/sawaryn.com\/?p=5264"},"modified":"2026-11-13T13:06:21","modified_gmt":"2026-11-13T13:06:21","slug":"data-act-saas-terms-switching-procedure","status":"publish","type":"post","link":"https:\/\/sawaryn.com\/en\/publikacje\/data-act-saas-terms-switching-procedure\/","title":{"rendered":"The Data Act in SaaS Terms. How to Draft a Switching Procedure That Will Hold Up in a Dispute."},"content":{"rendered":"

Your SaaS terms contain one sentence: \u201cAfter termination of the agreement, the Customer\u2019s data will be deleted within 30 days”. It sounds safe. As of 12 September 2025, it is unlawful \u2014 and that is the least of your problems.<\/p>\n

Chapter VI of Regulation (EU) 2023\/2854 (Data Act)<\/a> 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 \u2014 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\u2019s data. Yet a typical data processing agreement provides for data to be deleted \u201cno later than within 30 days”. These documents contradict each other.<\/p>\n

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 \u2014 in a single sentence of the precedence clause in the data processing agreement.<\/p>\n

Key concepts before we proceed<\/h2>\n

Before moving on to the specifics, it is worth clarifying several terms used in the Regulation that will recur throughout this article.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Concept<\/th>\nWhat it means under the Data Act<\/th>\n<\/tr>\n<\/thead>\n
Data processing service<\/strong><\/td>\nA cloud or SaaS service in which the provider stores and processes customer data on its own infrastructure \u2014 the typical subscription model<\/td>\n<\/tr>\n
Switching<\/strong><\/td>\nA procedure in which a customer transfers data and digital assets from one provider to another or to its own infrastructure<\/td>\n<\/tr>\n
Transitional period<\/strong><\/td>\nThe period following notice of termination during which the provider continues to provide the service with full continuity, enabling the customer to migrate<\/td>\n<\/tr>\n
Exportable data<\/strong><\/td>\nData entered by the customer into the application that is subject to export \u2014 excluding reference data and the provider\u2019s internal data<\/td>\n<\/tr>\n
Digital assets<\/strong><\/td>\nElements in digital form, including applications that the customer is entitled to use independently of its agreement with a particular provider<\/td>\n<\/tr>\n
Unfairness test (Article 13)<\/strong><\/td>\nA mechanism for assessing whether a unilaterally imposed contractual term grossly deviates from good commercial practice \u2014 if it does, it is not binding on the other party<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Two portability mechanisms that SaaS terms regularly confuse: Article 20 GDPR<\/strong> is a right held by a natural person against a personal data controller. Chapter VI of the Data Act<\/strong> 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 \u201cdata portability” clause referring to both provisions jointly, your legal framework is defective.<\/p>\n

Timeline of the switching procedure under the Data Act<\/h2>\n

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.<\/p>\n

Below is the full timeline that your terms must reflect as of 12 September 2025:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Stage<\/th>\nDeadline<\/th>\nWhat happens<\/th>\n<\/tr>\n<\/thead>\n
Customer request<\/strong><\/td>\nDay 0<\/td>\nThe customer submits a switching request in documentary form. The request should specify its purpose: migration to another provider, transfer to the customer\u2019s own infrastructure, or deletion of the data only<\/td>\n<\/tr>\n
Notice period<\/strong><\/td>\nMax. 2 months<\/td>\nThe customer may specify a shorter period. The agreement remains in force on its existing terms<\/td>\n<\/tr>\n
Transitional period<\/strong><\/td>\nMax. 30 calendar days<\/td>\nThe 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<\/td>\n<\/tr>\n
Technical infeasibility clause<\/strong><\/td>\n14 working days to give notice + an alternative period of up to 7 months<\/td>\nIf the 30-day transitional period is technically infeasible, the provider must notify the customer within 14 working days and propose an alternative<\/td>\n<\/tr>\n
Data retrieval period<\/strong><\/td>\nMin. 30 days after completion of the migration<\/td>\nThe service is no longer provided, but the provider ensures the availability and security of exportable data<\/td>\n<\/tr>\n
Notice before deletion<\/strong><\/td>\nMin. 7 days (contractual arrangement)<\/td>\nThe provider informs the customer of its intention to delete the data<\/td>\n<\/tr>\n
Termination of the agreement<\/strong><\/td>\nAfter completion of the procedure<\/td>\nThe agreement is deemed terminated; the provider informs the customer<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/p>\n

Who must implement this?<\/strong> 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.<\/p>\n

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.<\/p>\n

Contact us<\/a><\/p>\n

Five ways SaaS terms templates break down under the Data Act<\/h2>\n

1. One sentence about data deletion instead of a switching procedure<\/h3>\n

Typical SaaS terms: \u201cAfter termination of the agreement, the Customer\u2019s 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\u2019s right to extend the transitional period. A single sentence about deletion does not satisfy any of these requirements.<\/p>\n

2. No catalogue of exportable data or exclusions<\/h3>\n

Without a catalogue, the customer may demand the export of the provider\u2019s licensed reference data \u2014 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\u2019s internal data and reference databases licensed by the provider).<\/p>\n

3. No information layer outside the terms<\/h3>\n

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<\/a> 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.<\/p>\n

4. Trial period without a switching procedure<\/h3>\n

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<\/a> \u2014 leaving it without a specified deletion deadline. Extend the procedure to the free-of-charge agreement, with separate, shorter deadlines.<\/p>\n

5. No rule for incomplete requests<\/h3>\n

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 \u2014 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.<\/p>\n

The precedence clause in the data processing agreement \u2014 a hidden flaw in the entire procedure<\/h2>\n

This is where SaaS terms contain their greatest flaw \u2014 one their authors are unaware of.<\/p>\n

A typical personal data processing agreement<\/a> contains the following clause: \u201cIn 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”.<\/p>\n

It sounds reasonable. The problem is that, in a SaaS tool processing almost exclusively personal data (as is the case with most B2B products \u2014 from CRM and HR to AML\/KYC), this clause does three things at once:<\/p>\n\n\n\n\n\n\n\n
What the precedence clause does<\/th>\nEffect<\/th>\n<\/tr>\n<\/thead>\n
Replaces the Data Act procedure in the terms with the 30-day deletion deadline in the data processing agreement<\/td>\nThe entire multi-stage switching procedure becomes ineffective \u2014 in a dispute, the shorter deadline in the data processing agreement prevails<\/td>\n<\/tr>\n
Takes claims outside the financial cap on liability<\/td>\nThe 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<\/td>\n<\/tr>\n
Creates two conflicting audit regimes<\/td>\nTerms: an audit once every 12 months, at the customer\u2019s expense, with 30 days\u2019 prior notice. Data processing agreement: the right to conduct an inspection at any time, free of charge if ordered by the supervisory authority<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

What should you do about it?<\/strong> You have two options:<\/p>\n

    \n
  1. Narrow the precedence clause to substantive processing matters (purposes, scope, and categories of data), expressly excluding liability for damages and service termination deadlines<\/li>\n
  2. 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<\/li>\n<\/ol>\n

    Neither option is difficult. But neither will happen by itself.<\/p>\n

    Switching charges \u2014 phase-out schedule<\/h2>\n

    The schedule for phasing out switching charges directly affects the SaaS provider\u2019s business model:<\/p>\n\n\n\n\n\n\n\n
    Period<\/th>\nRule<\/th>\n<\/tr>\n<\/thead>\n
    12.09.2025 \u2013 12.01.2027<\/strong><\/td>\nThe provider may charge reduced switching fees, but they may not exceed the costs actually incurred by the provider<\/td>\n<\/tr>\n
    From 12.01.2027<\/strong><\/td>\nA complete ban on any charges for the switching procedure. The ban also covers migration and testing tools<\/td>\n<\/tr>\n
    Multi-cloud (egress)<\/strong><\/td>\nCharges for outbound data traffic when using the services of two providers in parallel remain permissible \u2014 up to the amount of the costs actually incurred<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    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 \u2014 all of these are the provider\u2019s responsibility.<\/p>\n

    The unfairness test under Article 13 \u2014 why your limitation of liability may not work<\/h2>\n

    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 \u2014 it concerns B2B relationships.<\/p>\n

    The mechanism works as follows:<\/p>\n

      \n
    1. A unilaterally imposed term (and SaaS terms are, by definition, imposed unilaterally) is subject to assessment<\/li>\n
    2. If it grossly deviates from good commercial practice and is contrary to good faith \u2014 it is not binding on the other party<\/li>\n
    3. The burden of proving that the term was not unilaterally imposed rests with the provider<\/li>\n<\/ol>\n

      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<\/strong>.<\/p>\n

      This has direct implications for the limitation of liability clause in SaaS terms. The standard sentence \u201cthe provider\u2019s liability is limited to the amount of X” may prove ineffective insofar as it covers damage caused intentionally or through gross negligence.<\/p>\n

      Hence the recommendation: a two-track limitation of liability<\/strong> \u2014 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 \u00a7 2 of the Polish Civil Code, which prohibits the exclusion of liability for intentionally caused damage.<\/p>\n

      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 \u2014 it means the absence of predictability.<\/p>\n

      Where SaaS documents say something different from the system<\/h2>\n

      The most serious defects in SaaS terms are not found in the terms themselves. They lie at the intersections between documents \u2014 where the security appendix promises something the system does not do.<\/p>\n\n\n\n\n\n\n\n\n\n
      Statement in the documents<\/th>\nActual situation<\/th>\nRisk<\/th>\n<\/tr>\n<\/thead>\n
      \u201cCentralised event logging and logging of every access to databases”<\/td>\nThe system stores only timestamps for the creation and modification of records, without a user activity log<\/td>\nThe lack of logs makes it impossible to determine the scope of an incident<\/a> \u2014 in decision ZSO\u015aS.421.25.2019<\/a>, the Polish Data Protection Authority identified the lack of traceability as a security risk and imposed a fine of PLN 50,000<\/td>\n<\/tr>\n
      \u201cCentralised identity management, including SSO and MFA support”<\/td>\nMFA is not enabled for application users \u2014 the description refers to a capability, not an implemented security measure<\/td>\nThe reader interprets the document as a statement that it has been implemented<\/td>\n<\/tr>\n
      \u201cRPO\/RTO parameters compliant with the contractual SLA”<\/td>\nThe terms contain no RPO\/RTO parameters<\/td>\nA reference to something that does not exist<\/td>\n<\/tr>\n
      \u201cPermanent deletion of data on request”<\/td>\nThe application marks records as deleted (soft deletion); there is no process for permanently purging the database<\/td>\nThe promise of permanent deletion and the statement that requests under Article 17 GDPR are supported are false<\/td>\n<\/tr>\n
      \u201cData in backups is deleted in accordance with the standard retention cycle”<\/td>\nThe retention cycle is not defined<\/td>\nOpen-ended storage period \u2014 a breach of Article 5(1)(e) GDPR (storage limitation)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Ask the application developer each of these questions before<\/strong> signing the documents. Not after.<\/p>\n

      SLA \u2014 three pitfalls that change the service level<\/h2>\n

      Support hours vs. 24\/7<\/h3>\n

      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<\/strong>.<\/p>\n

      For comparison, the Microsoft Power Platform documentation<\/a> 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.<\/p>\n

      Definition of downtime without exclusions<\/h3>\n

      If you do not define downtime negatively (what downtime is not<\/strong>), then reduced performance, longer processing times, an error in a single feature \u2014 or even an incorrect result generated by an AI model \u2014 become an SLA breach. A model hallucination becomes grounds for a service credit. Exclude this expressly.<\/p>\n

      Service credit after termination of the agreement<\/h3>\n

      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 \u2014 formally the customer\u2019s exclusive remedy \u2014 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.<\/p>\n

      AML and AI layers \u2014 additional obligations your terms do not address<\/h2>\n

      A SaaS tool is not an archive<\/h3>\n

      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<\/strong>. This obligation remains with the customer, not the tool provider.<\/p>\n

      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 \u2014 at the worst possible time.<\/p>\n

      What to include in the terms:<\/strong> three sentences at the beginning that define the nature of the application \u2014 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.<\/p>\n

      Language model providers classify your queries<\/h3>\n

      If your SaaS product uses a large language model (LLM)<\/a>, check the provider\u2019s terms. By default, OpenAI<\/a> 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.<\/p>\n

      This constitutes personal data processing if the prompts contain such data \u2014 and in an AML\/KYC<\/a> tool, they almost always do. Decide which document should disclose this: the subprocessor list, data processing agreement, or confidentiality clause.<\/p>\n

      AI Act \u2014 a date to remember<\/h3>\n

      The AI Act obligations for high-risk systems listed in Annex III and the transparency obligations under Article 50 apply from 2 August 2026<\/strong>. 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<\/a> requires an assessment that a system does not qualify to be documented, not merely declared.<\/p>\n

      Access management \u2014 a deadline that will not withstand scrutiny<\/h2>\n

      A deadline of \u201cwithout undue delay, no later than within 21 days” for revoking a former customer employee\u2019s access is indefensible under Article 32 GDPR in a tool that processes data concerning suspected criminal offences.<\/p>\n

      Choose one access management model and shorten the deadline:<\/p>\n\n\n\n\n\n\n
      Model<\/th>\nHow it works<\/th>\nAccess revocation deadline<\/th>\n<\/tr>\n<\/thead>\n
      Customer administrator<\/strong><\/td>\nThe customer manages user accounts itself through the administration panel<\/td>\nImmediately \u2014 responsibility lies with the customer<\/td>\n<\/tr>\n
      Managed by the provider<\/strong><\/td>\nThe customer submits a request and the provider carries it out<\/td>\nHours or business days \u2014 not weeks<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Separate the deadline for revoking a former user\u2019s access from the deadline for blocking an account after termination of the agreement. These are two different situations with different levels of risk.<\/p>\n

      Penalties \u2014 what we know and what we do not yet know<\/h2>\n

      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)<\/a> provides for the President of UKE to be designated as the main authority and for administrative fines to be introduced.<\/p>\n

      As of the publication date of this article, the adoption of the Polish implementing act has not been confirmed<\/strong>. This means that:<\/p>\n

        \n
      1. There is no national authority enforcing Chapter VI of the Data Act<\/li>\n
      2. There is no national catalogue of penalties<\/li>\n
      3. The Regulation itself applies directly \u2014 providers\u2019 obligations apply regardless of the status of national legislation<\/li>\n<\/ol>\n

        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 \u2014 the risk that an entire limitation of liability clause will prove ineffective in a dispute exists regardless of whether an authority imposes a fine.<\/p>\n

        The scale of the issue \u2014 more than half of EU companies use SaaS<\/h2>\n

        According to Eurostat data for 2025<\/a>, 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.<\/p>\n

        The European Commission has developed non-binding Standard Contractual Clauses (SCCs) for cloud computing contracts<\/a>, 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.<\/p>\n

        Checklist \u2014 twelve questions for your SaaS terms<\/h2>\n

        Before sending your document package to the customer, go through this list:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
        No.<\/th>\nQuestion<\/th>\nWhere to find the answer<\/th>\n<\/tr>\n<\/thead>\n
        1<\/td>\nDo the terms contain a separate section on switching with a full timeline (request \u2192 notice \u2192 transitional period \u2192 data retrieval \u2192 deletion)?<\/td>\nTerms \u2014 agreement termination section<\/td>\n<\/tr>\n
        2<\/td>\nDo the data processing agreement and the terms specify consistent data deletion deadlines?<\/td>\nComparison of both documents<\/td>\n<\/tr>\n
        3<\/td>\nIs the precedence clause in the data processing agreement limited to substantive processing matters?<\/td>\nData processing agreement \u2014 final provisions<\/td>\n<\/tr>\n
        4<\/td>\nIs there a catalogue of exportable data and a catalogue of exclusions?<\/td>\nAppendix to the terms<\/td>\n<\/tr>\n
        5<\/td>\nIs information about formats, structures, and the jurisdiction of the infrastructure publicly available?<\/td>\nProvider\u2019s website<\/td>\n<\/tr>\n
        6<\/td>\nIs the trial period covered by the switching procedure and the data processing agreement?<\/td>\nTerms + data processing agreement<\/td>\n<\/tr>\n
        7<\/td>\nDoes the SLA define downtime both positively and negatively (including the exclusion of AI errors)?<\/td>\nSLA appendix<\/td>\n<\/tr>\n
        8<\/td>\nDoes the service credit work after termination of the agreement?<\/td>\nSLA appendix<\/td>\n<\/tr>\n
        9<\/td>\nIs the deadline for revoking a former user\u2019s access measured in hours\/days rather than weeks?<\/td>\nTerms or security appendix<\/td>\n<\/tr>\n
        10<\/td>\nDo the security statements (logs, MFA, RPO\/RTO, backup retention, deletion) reflect the system\u2019s actual architecture?<\/td>\nComparison of the security appendix with the technical documentation<\/td>\n<\/tr>\n
        11<\/td>\nDo the terms define the nature of the application (operational tool vs. archive)?<\/td>\nTerms \u2014 general provisions<\/td>\n<\/tr>\n
        12<\/td>\nIs the language model provider disclosed in the subprocessor list, together with information about prompt retention?<\/td>\nSubprocessor list<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        How we can help your company put its SaaS documents in order<\/h2>\n

        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 \u2014 and making decisions that go beyond the wording of the agreement itself.<\/p>\n

        We support SaaS providers and technology companies in three ways:<\/p>\n

          \n
        1. Compliance audit<\/strong> \u2014 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<\/li>\n
        2. Redrafting the contractual framework<\/strong> \u2014 switching section, catalogue of exportable data, SLA, personal data role map, and alignment of the terms with the data processing agreement<\/li>\n
        3. Complete document package<\/strong> \u2014 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<\/li>\n<\/ol>\n

          We combine IT law, data protection, and contract law in a single model \u2014 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.<\/p>\n