SaaS agreement: the clauses your customers will ask for

A B2B SaaS agreement usually combines three documents: terms of service covering access, price, term, termination and liability; a service level agreement (SLA) for uptime and support; and a data processing agreement (DPA), which Article 28 of the GDPR requires whenever you handle personal data on behalf of EU customers. Since 12 September 2025, the EU Data Act adds mandatory clauses on switching providers.

This article is a checklist, not legal advice. Use it to prepare the conversation with your lawyer, who is the only person who can draft an agreement that fits your business, your customers and your governing law. The texts cited were checked on 3 November 2026.

It covers the agreement between a SaaS company and its customers. The contract between a business and the agency that builds its software is a different topic, covered in software development contract clauses.

The documents in a SaaS agreement

For self-serve subscriptions, terms accepted online with the DPA attached are often enough. For enterprise accounts, expect to negotiate every document.

Terms of service: the essential clauses

Scope and access. The customer gets a right to use the service for the subscription term, not ownership of the software. State how many users or how much volume is included, and what happens beyond it.

Term and renewal. Monthly or annual, automatic renewal or not, notice to cancel. The clause must match what your billing system actually does.

Price changes. Say how prices can change, how much notice customers get, and their right to cancel if they disagree. Our guide on how to price a B2B SaaS product covers changing a price list without losing customers.

Payment. Payment terms, late fees and collection costs are regulated in many countries, including across the EU. Align the clause with your governing law, and with your billing setup, covered in SaaS subscription billing with Stripe.

Suspension. What happens when an invoice goes unpaid: restricted access, read-only mode, suspension after reminders? Write down the rule your application actually enforces.

Customer data. The customer stays in control of its data. The agreement says how it exports it, in what format, and when it is deleted after the contract ends.

Liability. A liability cap, often tied to fees paid over a period, and the exclusion of certain kinds of damage are common. Whether they hold depends on the governing law and the circumstances: this is the clause where your lawyer's view matters most.

Intellectual property. The software stays yours, the customer's data and content stay theirs. Cover feedback and anonymised usage data explicitly.

Governing law and jurisdiction, especially if you sell abroad.

The service level agreement

An SLA turns a vague promise ("the service is reliable") into measurable commitments. It usually covers four things.

Uptime. A percentage, measured over a period, with a stated method. Do the arithmetic before you pick one: a thirty-day month has 43,200 minutes, so 99.9% allows 43 minutes of downtime and 99.5% about 3 hours 36 minutes. Define exclusions too: announced maintenance, outages caused by the customer, force majeure.

Support. Channels, hours, and a response time for each severity level: service down, feature degraded, general question.

Backups and recovery. How often backups run, how long they are kept, and the maximum amount of data an incident could lose.

Service credits. When you miss the target, the usual remedy is a capped credit on the subscription. Uncapped compensation puts the company at risk.

The rule of prudence: never promise more than your own hosting provider guarantees you. If you run on a cloud platform, its uptime commitment is a ceiling for yours.

The data processing agreement (DPA)

When your SaaS stores personal data on behalf of customers (their staff, their clients, their contacts), you are usually their processor under the GDPR. EU customers have to put this contract in place wherever your company is based, and enterprise buyers outside the EU often ask for an equivalent. Article 28 requires a contract that describes the subject matter, duration, nature and purpose of the processing, the types of data and categories of people, and commits the processor to:

1. process data only on the customer's documented instructions;
2. bind authorised staff to confidentiality;
3. take the security measures required by Article 32;
4. engage another processor only with the customer's written authorisation, specific or general; under a general authorisation, inform the customer of changes so it can object;
5. help the customer answer requests from the people concerned;
6. help the customer meet its security, breach notification and impact assessment duties;
7. delete or return the data at the end of the service, at the customer's choice;
8. provide the information needed to demonstrate compliance, and allow audits.

Two practical points. Keep your own list of subprocessors (hosting, email delivery, payments, support desk, AI provider) up to date and share it. And under Article 33, notify the customer of any personal data breach without undue delay, so that it can notify its regulator, where feasible within 72 hours.

Looking for a DPA template? The European Commission adopted standard contractual clauses between controllers and processors (Decision 2021/915), which meet the requirements of Article 28. They are a solid base; you complete the annexes for your service. Our GDPR checklist for business applications covers what the software itself has to support.

The EU Data Act: switching providers

Regulation (EU) 2023/2854, in force since 12 September 2025, covers "data processing services" and, in recital 81, explicitly names Software as a Service. Its Chapter VI deals with switching. Article 25 requires a written contract, made available before signature, that includes at least:

• a notice period of no more than two months to start switching;
• a transition period of no more than 30 calendar days, during which the service continues; if that is technically impossible, the provider must explain why within 14 working days and propose another period of no more than seven months;
• an exhaustive list of exportable data and digital assets;
• a data retrieval period of at least 30 calendar days;
• full deletion of the data once switching is complete.

Article 29 phases out switching charges: until 12 January 2027 they may be charged but limited to costs directly linked to the switch; from that date, they are banned.

Note the specific regime in Article 31: some obligations, including the ban on switching charges, do not apply to services where most main features were custom-built for one customer and which are not offered at broad commercial scale through the provider's catalogue. A SaaS product sold to many customers is unlikely to fall under it, but have a lawyer confirm your case. The customer's side of the topic is in our guide to avoiding software vendor lock-in.

What enterprise customers add

• A security questionnaire, sometimes long, and the security annex that goes with it.
• Data residency, and the list of subprocessors outside the EU.
• Audit rights, which Article 28 already provides for, with practical terms (notice, frequency, cost).
• Proof of professional liability insurance.
• A dedicated environment, which is as much an architecture question as a contract one; our article on multi-tenant SaaS architecture explains how to prepare for it.

The most common mistakes

• Copying a template found online, written for another jurisdiction, another business or another company size.
• Promising uptime your hosting provider does not guarantee.
• Forgetting subprocessors: the email service or AI provider added along the way must appear on the list.
• Letting contract and product drift apart: a suspension rule, an export deadline or a retention period written in the agreement must exist in the software.
• Ignoring the Data Act in terms written before 2025.

What the software has to support

Much of a SaaS agreement is executed in code. Before signing your first customers, check that your application can:

• export all of one customer's data, in a documented format;
• delete all of one customer's data, and only theirs;
• restrict access according to the non-payment rule in your terms;
• measure uptime the way the SLA defines it;
• log access to data, to answer an audit or investigate a breach.

LPR Studio builds software; we do not draft contracts. When we build a SaaS product, we design these capabilities in from the start; the clauses themselves are for your lawyer.

Where to start

1. List your subprocessors and the personal data your service handles.
2. Measure your real uptime before you promise one.
3. Work with a lawyer on the terms, the DPA and the SLA, starting from how your service actually runs.
4. Check the product against the agreement: export, deletion, suspension, measurement.
5. Review everything once a year, and whenever you add a subprocessor.