Why the SaaS agreement is business-critical for both parties
Software as a service, SaaS, has become the standard way to deliver and buy software. Instead of installing a program on its own servers, the customer accesses the service over the internet and pays on an ongoing basis. For the customer, this means lower barriers and faster adoption. For the vendor, it means recurring revenue and a closer relationship with the customer. But precisely because the service is continuous, and because the customer’s business often comes to depend on it, the SaaS model places particular demands on the agreement.
A SaaS agreement governs the relationship between vendor and customer throughout the time the service is used. It is not a one-off delivery but an ongoing commitment: the service must work, support must be available, data must be secure and accessible, and both parties must know what happens when the agreement eventually ends. A well-considered agreement protects the customer against outages and lock-in, and the vendor against unreasonable demands and unclear liability.
This article walks through what a sustainable SaaS agreement must cover, from both the customer’s and the vendor’s perspective, the most common mistakes, and the risks that follow from unclear agreements.
What a SaaS agreement must cover
A SaaS agreement differs from a traditional licence agreement in that the service is delivered continuously. This shifts the emphasis from what is delivered to how well it works over time.
Availability, SLA and support
At the heart of many SaaS agreements is the service level agreement, or SLA. This governs the uptime the vendor promises, often expressed as guaranteed availability in percent, and what happens if it is not met – for example in the form of price reductions or other compensation. The SLA should also describe the scope of support: which channels are available, what response times apply and how serious faults are prioritised. For the customer, this is a protection against the business being paralysed by outages. For the vendor, it is important that the commitments are realistic and that planned maintenance is excluded, so that promised levels can actually be met.
Data, ownership and data portability
One of the most decisive questions is who owns and controls the data the customer puts into the service. As a rule, the agreement should establish that the customer’s data belongs to the customer, and that the vendor only processes it to deliver the service. Just as important is data portability: the customer should have the right, on an ongoing basis and at the end of the agreement, to retrieve its data in a usable format. Without such a provision, the customer risks lock-in, where it becomes practically impossible to switch vendors.
Pricing, renewal and termination
The agreement should clearly state the price, how it may be adjusted and how payment works. Particular attention should be paid to renewal terms. Many SaaS agreements renew automatically unless terminated in time, and price increases can occur at renewal. The customer should ensure that notice periods and pricing mechanisms are predictable, while the vendor has an interest in stable revenue. A balanced provision protects both parties against unpleasant surprises.
Liability, liability caps and intellectual property
No system is entirely fault-free, and the agreement needs to allocate the risk if something goes wrong. Vendors almost always work with liability caps – for example a cap tied to the fees the customer has paid over a given period – and exclusions for indirect damages. The customer should check that the cap is reasonable relative to the importance of the service. The agreement should also govern intellectual property: the vendor normally retains the rights to the software itself, while the customer receives a right of use during the term, and the vendor should warrant that the service does not infringe third-party rights.
GDPR and the link to the DPA
Because most SaaS services process personal data on the customer’s behalf, a processor relationship almost always arises. This means the SaaS agreement needs to be supplemented by a data processing agreement, a DPA, that meets GDPR’s requirements. The agreement should govern where data is processed, how subcontractors are handled and what applies to any transfers outside the EU. This link is so central that a SaaS agreement without a functioning DPA is rarely complete.
A practical example: when the agreement forgot the ending
Imagine a company that adopts a new business system as SaaS. The rollout goes well, the system quickly becomes the hub of operations and all important data is gathered there. The agreement that was signed was the vendor’s standard terms, and no one gave particular thought to what would happen at the end of the agreement.
Three years later, the company wants to switch vendors. It then turns out that the agreement gives no clear right to retrieve data in a usable format, that the notice period is long and that the agreement has already renewed automatically for another term. The company is stuck – not because the vendor is doing anything wrong, but because the agreement never governed the exit. The migration becomes expensive and drawn out, and the negotiating position is weak because the business cannot operate without the system.
With a well-considered agreement, the exit would have been predictable. A data portability clause would have granted the right to export data in a standard format, a reasonable notice period would have given time to migrate, and clear renewal terms would have ensured no period renewed by mistake. The same switch would then have been a planned transition rather than a crisis.
Common mistakes businesses make
The most common mistake on the customer side is signing the vendor’s standard terms without reviewing them. Standard agreements are written from the vendor’s perspective and often contain strong liability caps, broad rights to change the service and sparse commitments on data and exit.
A second mistake is focusing on price and features but overlooking what happens at the end of the agreement. The question of data portability and exit feels remote at the start, but that is precisely when it must be regulated.
A third mistake is forgetting the GDPR link. Many SaaS agreements lack a functioning DPA, even though the service processes personal data, meaning the customer breaches data protection rules without knowing it.
On the vendor side, a common mistake is promising more than can realistically be met – for example high guaranteed availability with no maintenance exclusions. Another is having unclear or uncapped liability commitments, which can become very costly if a single customer suffers a serious fault.
The legal risks of unclear SaaS agreements
For the customer, the greatest risk is operational dependence combined with weak commitments. If the service is down and the SLA is vague, there is rarely any real remedy, while the business stands still. Another risk is lock-in: without a right to data portability, switching vendors can become so expensive and complicated that it is effectively impossible. On top of this comes the data protection risk if the DPA is missing or deficient.
For the vendor, the risk lies above all in unreasonable or unclear commitments. An SLA with promises that cannot be kept, or liability without a reasonable cap, can lead to claims that threaten profitability. Unclear intellectual property terms can also create disputes over who owns what, particularly when the service is developed further together with customers.
What both parties have in common is that unclear agreements move disputes from the negotiating table to after-the-fact conflicts, where the outcome is uncertain and the cost high.
Recommended actions
Treat the SaaS agreement as a business-critical document, not a formality. As a customer, you should review the vendor’s terms rather than accept them unread, and negotiate in particular on the SLA, data portability, termination and renewal, and liability caps. Ensure a DPA is in place and meets GDPR’s requirements, and check where your data is processed.
As a vendor, you should ensure your commitments are realistic and clear, that the SLA has reasonable exclusions, and that liability caps and intellectual property terms are balanced and defensible. Clear agreements reduce the risk of disputes and build trust with customers.
Whichever side you are on, the agreement should be reviewed on an ongoing basis. Services evolve, legal requirements change and the business relationship matures, and the agreement needs to keep pace so that it continues to reflect reality.
Frequently asked questions about SaaS agreements
What is the difference between a SaaS agreement and an ordinary licence agreement?
A traditional licence agreement grants the right to install and use software, often for a one-off fee. A SaaS agreement instead governs an ongoing service delivered over the internet, where the emphasis is on availability, support, data and the terms that apply throughout the term.
What is an SLA and why does it matter?
SLA stands for service level agreement and describes the service level the vendor promises – such as availability, response times and support – and what happens if the levels are not met. For the customer, the SLA is the main protection against outages, and for the vendor a way to clarify and limit its commitments.
Who owns the data we put into a SaaS service?
As a rule, the agreement should establish that the customer’s data belongs to the customer and that the vendor only processes it to deliver the service. If the agreement is unclear on this point, it should be clarified, since ownership and data portability are decisive for the ability to switch vendors.
Does a SaaS agreement need to be supplemented by a DPA?
Yes, in the vast majority of cases. If the service processes personal data on the customer’s behalf, a processor relationship arises, and GDPR then requires a DPA alongside the SaaS agreement itself. The two documents should be linked.
What should we watch out for regarding automatic renewal?
Many SaaS agreements renew automatically unless terminated within a certain period, and the price may increase at renewal. Check notice periods and pricing mechanisms before signing, and keep track of renewal dates so you are not tied in for another term by mistake.
How do we protect ourselves against vendor lock-in?
The most important protection is a clear right to data portability – the ability to retrieve your data in a usable standard format both on an ongoing basis and at the end of the agreement – together with a reasonable notice period that gives time to migrate to a new solution.
Conclusion
A SaaS agreement is about an ongoing relationship in which the customer’s business often comes to depend on the vendor’s service. That is precisely why the long-term questions – availability, data, exit and liability – determine whether the agreement is sustainable, rather than the price at the outset. A balanced agreement protects both customer and vendor and turns potential disputes into predictable processes.
Lawgent helps both vendors and customers negotiate, draw up and review SaaS agreements that are clear, balanced and compliant with GDPR. We combine experienced commercial-law advice with AI-driven efficiency, so that you get agreements that protect your business without slowing it down – faster and more cost-effectively than at a traditional firm. Facing a new cloud agreement or want to review an existing one? Contact Lawgent for a review of your SaaS agreement.
