SaaS Agreements: keynote

SaaS Agreements: Key provisions of international technology contracts Practical guidance for technology companies and their customers

Mainstream

An international SaaS contract is not a subscription to a software product. It is the allocation of risks, responsibilities and responsibilities in a constantly changing regulatory environment.

The question is not how much the licenses cost. The main question is whether the contract retains commercial meaning after two to three years of operation, when the technology, applicable law or the model of data processing changes.

Therefore, effective work with SaaS agreements begins with three checks:

• Who is responsible for what in the data chain and before regulators?
• What happens when a service stops, data leakage or a change of provider.
• Where and under what rules will disputes be resolved if the contract ceases to work?

If these three issues are not resolved at the contract construction stage, the company may suffer not just losses, but a complete loss of access to critical infrastructure or regulatory sanctions.

When a SaaS Agreement is Needed

In-depth contract work is required if:

• The technology company brings the SaaS product to the EU market;
• the corporate client acquires a cloud solution with sensitive data processing;
• The service is built on a public cloud with cross-border transfer of personal data;
• the product has built-in artificial intelligence components that fall under the EU AI Act;
• SaaS is subject to industry regulation (finance, healthcare, critical infrastructure)
• Data processing affects several jurisdictions with different legal regimes;
• The Data Processing Agreement (DPA) is signed as part of the primary contract.
• Exit or migration from one cloud provider to another
• the limitation of liability that may leave the customer without an effective remedy is discussed;
• The SaaS project requires compliance with DORA, NIS2 or EU cyber standards.

A mistake that most parties make

Many companies start with the question:

What SLA is available to prescribe?

That's the wrong first question.

The right question is:

What combination of contractual arrangements will ensure business continuity, legality of data processing and the real possibility to switch to another provider without catastrophic losses?

Sometimes the key is not the percentage of uptime, but the obligation to port data. Sometimes it is not the size of penalty points for a simple one, but the right to early termination in case of repeated incidents. Sometimes, not the limit of liability, but exceptions for data privacy violations. An international SaaS contract does not require a template, but a risk architecture.

Step 1. Determine the legal nature of the decision provided

First, it is necessary to clearly understand: What exactly is provided - a service, license or a hybrid of them. This depends on:

• intellectual property;
• responsibility for quality;
• guarantees;
• tax consequences;
• the possibility of retaining ownership.

The qualification of SaaS as a service in most EU legal order means that the customer does not receive a copy of the program, but uses the functionality remotely. This reduces the risks associated with exhaustion of rights, but shifts the focus to quality assurance and continuity of access.

Step 2. Deployment model and cross-border data transfer

The SaaS solution can be deployed:

• Public cloud (AWS, Azure, GCP)
• in the private cloud of the customer;
• In hybrid infrastructure.

In each option, it is critical to determine:

• where the data is physically located (data residency);
• who and from which jurisdiction provides technical support;
• Whether the transfer of personal data to third countries requires protection mechanisms under the GDPR (Standard Contractual Clauses, Binding Corporate Rules, adequacy decision).

European regulators are closely analyzing cross-border flows, and the lack of a clear description of the data architecture in the contract is a self-contained compliance risk.

Step 3. Establish a working service level agreement (SLA)

The SLA in an international contract is not just about availability numbers. It should include:

• Methods for calculating availability (excluding scheduled maintenance);
• reaction time, elimination time, escalation;
• service credits, which should be real compensation, not a nominal discount;
• the right to termination at chronically low quality;
• Measurable performance indicators (latency, throughput)
• transparency of monitoring and the right of the customer to an independent quality audit.

Without the right to emergency exit and without the obligation of the provider to facilitate migration, the SLA does not protect the customer’s business.

Step 4. Evaluate the roles and obligations of the GDPR and the Data Processing Agreement

The SaaS provider that processes personal data is almost always a processor. The customer is the controller (controller). The contract should:

• clearly fix the subject, purpose, nature and timing of processing;
• contain a list of data types and categories of subjects;
• to impose on the provider the obligation to process data only according to documented instructions;
• provide prior consent to the involvement of sub-processors;
• to ensure assistance in fulfilling data subjects’ requests and notification of leaks;
• provide for the deletion or return of data at the end of the contract.

In the EU, DPA is not an optional application – it is a mandatory element of a SaaS contract, a distortion in which can entail joint administrative liability.

Step 5. Deal with Data Rights and Intellectual Property

Confusion in this block is the source of the most severe commercial disputes. The contract shall clearly state:

• Who owns the data uploaded by the customer (usually the customer);
• Who owns the derivative data, analytics, metadata;
• Whether the provider can use anonymized data to improve the product or train AI models
• what licenses the customer receives for the interface, integration modules and documentation;
• The provider’s obligation not to use customer data for competing products.

With the evolution of the EU Data Act, the right of a customer to port data between cloud providers will soon become a mandatory requirement, and the contract must either take it into account or prepare the parties for the inevitable change.

Step 6. Check the Limitation of Liability and its Exclusions

In SaaS, the typical provider liability limit is a 12-month service fee. That could be catastrophically low. Parties should agree:

• exceptions to the limit: breaches of confidentiality, data privacy, intent, gross negligence, violation of intellectual property rights;
• the liability regime for the actions of subcontractors;
• indemnification in favor of the customer on claims of third parties;
• liability for regulators’ fines imposed due to the provider’s fault.

The weakness of many SaaS contracts is the situation when the client’s losses from downtime are thousands of times higher than the cost of the service, and the limit leaves him without reimbursement. It requires an individual architecture, not a template.

Step 7. Review of the Exit Plan and the Exit Plan

The contract should describe not only the beginning of the work, but also its completion. Exit mechanisms include:

• the time and format of the return of all customer data;
• The obligation of the provider to provide porting in a standard machine-readable format;
• Transition assistance – usually 3-12 months after termination
• the procedure for data destruction by the provider and the certificate of deletion;
• Transition services cost: Many providers hide it in opaque tariffs.

In regulated sectors, the right to unimpeded migration will soon become a regulatory obligation, not a wish.

Step 8. Address new regulatory requirements for technology in the EU

A modern SaaS contract cannot ignore the rapidly growing array of pan-European norms.

• AI Act – if SaaS contains AI components, it is necessary to define the risk category, transparency and human oversight responsibilities, and the possibility of prohibited practices.
• Digital Services Act (DSA) – if the provider acts as an intermediary platform, additional obligations will arise.
• Cyber Resilience Act – requirements for cyber security software products with access to the EU market;
• Data Act – mandatory provision of switching between cloud providers and access to data generated by devices.

The contract must not only invoke compliance with applicable law, but also share the burden of adapting to new requirements, otherwise one of the parties will incur unexpected costs.

Step 9. Select applicable law and dispute resolution mechanism

There are several approaches to international SaaS:

• exclusive jurisdiction of the courts of the provider’s country;
• arbitration (ICC, LCIA, SCC, DIS);
• hybrid clauses.

The choice depends on:

• negotiating positions of the parties;
• location of assets and data centers;
• the need for confidentiality;
• Prospects of enforcement in the jurisdictions where the client is located.

It's important to remember: The GDPR and DSA apply extraterritorially, so the choice of non-EU law does not exempt from European public regulation.

Step 10. Develop a contract management strategy for the full term

The SaaS contract is not static. He demands:

• regular verification of the compliance of data processing with the declared purposes;
• Updating the list of sub-processors;
• Monitoring changes in the regulatory landscape;
• A plan to review the SLA as the criticality of the service increases;
• Escalate operational problems to legally relevant notifications.

Weak contract management makes even a well-written contract inoperable over time.

Balance of interests: provider vs customer

How to strengthen your position before signing a SaaS contract

The best protection starts at the Due Diligence and Request for Proposals (RFP) stage.

• request and analyze the typical DPA provider prior to commercial negotiations;
• Include specific data port and security certification requirements in the RFP (ISO 27001, SOC 2);
• Internally classify data and determine which data is acceptable to transfer to the cloud.
• check the country of incorporation of the provider and its ultimate beneficiaries for sanctions risks;
• simulate the emergency shutdown scenario and assess how the contractual arrangements ensure continuity;
• to fix the obligation of the provider to insure professional liability for the agreed amount.

Common mistakes in SaaS agreements

1. Using a template without adapting to GDPR and Data Act leads to the illusion of legality in case of real violations.
2. Mixing the concept of license and service in a contract creates uncertainty with the rights to software and data.
3. Failure to verify the chain of sub-processors is the risk of data leakage through an unverified subcontractor.
4. Ignoring the obligation to notify incidents is a violation of the GDPR deadline (72 hours).
5. Accept a liability limit of “monthly fees” when processing critical data.
6. Forget about the right to audit – without it it is impossible to verify the actual compliance with security conditions.
7. Not agreeing on the exit mechanism – the customer is in a technological trap.
8. To ignore the provider’s right to unilaterally change the terms is permissible only with a clear period of notice and the right of termination.
9. Not to take into account AI-specificity – models can be trained on customer data without explicit consent.
10. Not to lay the mechanism of adaptation to the new regulatory acts of the EU – the contract becomes obsolete at the time of entry into force of the new regulation.

Checklist for the parties to the SaaS contract

Before signing, you need to answer 15 questions:

1. Are the controller and processor roles defined under the GDPR?
2. Where are the data and all of their backups physically located?
3. Is there a written permit for cross-border transfer?
4. What is the real SLA and how to calculate it?
5. Is there a procedure for notifying security breaches?
6. What data is considered confidential and how is it protected?
7. Who owns the aggregated and analytical data?
8. What exceptions to the limitation of liability are agreed upon?
9. Is there a right to audit and who pays for it?
10. What happens to the data when the contract is terminated?
11. Is the provider obliged to facilitate migration and how much does it cost?
12. Are the requirements of the AI Act, DSA, Data Act, and other relevant?
13. Which court or tribunal will consider the dispute?
14. Can I transfer the contract during a business restructuring?
15. What is the mechanism for amending the DPA and the main contract?

What a Strong Contract Strategy Looks Like

A strong strategy usually includes five levels:

1. Business & Data Mapping: Understanding business processes, data flows and service criticality before negotiations begin.
2. Regulatory Mapping defines all EU rules applicable today and for the foreseeable future, from GDPR to Cyber Resilience Act.
3. Contractual Architecture: A clear, consistent SLA, DPA, license terms, liability and exit plan.
4. Operational Integration: Incorporating contractual requirements into the working procedures of both parties (security instructions, notices).
5. Pre-Conflict & Dispute Strategy Pre-defined sequence of actions in case of an incident, SLA violation or regulatory review, including escalation and mediation.

Without a level five, even a perfectly written contract may not protect a business in a crisis.

FAQ

Under GDPR – yes, if the provider processes personal data on behalf of the customer. The DPA may be part of the main contract, but must be legally separate and meet the requirements of Article I. 28 GDPR.

Can the provider use the customer’s data to train AI?Only with explicit, separate consent, as recorded in the contract. Without this, the use of the data for the provider’s own purposes, including model training, is a violation of the purposes of the processing.

What to do if a SaaS provider refuses to change its template?Ranking risks and identifying critical inadmissible positions are necessary. Sometimes it is wiser to accept a standard document but get additional guarantees through insurance, certification and audit rights than to lose a contract without having real leverage.

How to ensure the execution of exit obligations if the provider is in a prebankrupt state?Include in the contract the right to escrow deposit of source code (if applicable) or to receive data in a standard format in advance on a regular basis. In critical cases, consider the requirement for a bank guarantee for the transition period.

If the client is an EU financial institution, the Digital Operational Resilience Act (DORA) directly regulates contracts with ICT service providers, including SaaS. The contract must contain the provisions prescribed by DORA and allow for direct audit by the regulator.

To prescribe that changes affecting the subject of processing, SLA, price or data rights, take effect only after the written consent of the client or give the client an unconditional right to terminate without penalties and with full support for migration.

Related services

• Technology, Digital Business & Data Protection
• International Commercial & Tech Contracts
• Artificial Intelligence, AI Act & Emerging Tech Regulation
• Cross-Border Data Transfers & GDPR Compliance
• IT Disputes, Cloud & Software Litigation
• Cybersecurity, DORA & NIS2 Compliance
• Commercial IP & Licensing

Related material

• How to Build a Legal Framework for Cross-border Data Transfers in the EU
• DPA under GDPR: 12 Mistakes That Deprive the Contract of Validity
• EU AI Act: What will change for SaaS products with AI components
• Data Act and Right to Switch Between Cloud Providers
• Limitation of Liability in IT Contracts: what works in Europe
• Exit plan in SaaS: How to make sure you have a real opportunity to leave
• SLA in an international cloud contract: commercial instrument, not formality
• Tax and regulatory risks of SaaS models in different EU jurisdictions
• How to Check a Technology Partner Before Integration

Conclusion

The SaaS agreement is not a subscription, but a complex organism, where data protection obligations, new technological regulations, commercial risks and exit architecture intersect.

A strong position is not based on trying to fit a deal into a standard pattern, but on understanding exactly what provisions in a particular project are critical, how they will work in two or three years, and what will happen if the relationship is to end in conflict.

The winner in international technology contracts is not the one who insisted on his editorial board, but the one who has foreseen in advance how the contract will behave in the moment of regulatory review, security incident or emergency migration.