SaaS contracts are often sold as standard.
Standard terms. Standard pricing. Standard risk position.
But for scaling tech companies, SaaS agreements are rarely just admin. They sit under key parts of the business, from customer delivery and product infrastructure to finance, HR, security and data management.
That means the contract matters.
The most common SaaS negotiation points usually come down to one issue: the supplier wants a low-touch, one-to-many delivery model. The customer needs enough legal and operational protection if the platform fails, changes, leaks data or becomes difficult to exit.
Here are the areas that tend to matter most.
1. Liability and risk allocation
Liability is usually one of the first points to be negotiated.
Suppliers often try to cap their total liability at 100% of the fees paid in the previous 12 months. That may work for a low-value tool with limited business impact. It may not work where the SaaS platform supports core operations, customer services or regulated activity.
Customers often push for higher caps or separate caps for specific risks, such as:
- Data protection breaches
- Confidentiality breaches
- Security failures
- IP infringement
- Wilful misconduct or fraud
The other issue is excluded losses.
Many SaaS contracts exclude indirect losses, consequential losses, loss of profit, loss of revenue, loss of goodwill and loss of data. The problem is that, in practice, those may be exactly the losses a customer is most worried about.
Customers may therefore negotiate carve-ins, making clear that certain costs are still recoverable. For example:
- Wasted expenditure
- Costs of replacement services
- Data restoration costs
- Regulatory investigation costs
- Customer remediation costs
IP infringement indemnities are also a key point. Customers usually want comfort that, if a third party claims the software infringes their IP rights, the supplier will step in and cover the claim.
Suppliers may try to cap that indemnity, narrow it by territory or limit when it applies. For customers using SaaS as part of a customer-facing product or critical workflow, that deserves proper review.
2. Service levels and remedies
Uptime sounds simple until you read the detail.
A contract might promise 99.9% availability, but the real question is how that figure is calculated. Is availability measured at the supplier’s infrastructure? At the API? At the user interface? From the customer’s location?
Those details matter.
Suppliers usually exclude scheduled maintenance, emergency maintenance, beta features, customer-side issues, third-party failures and force majeure events from service level calculations.
Customers may want to negotiate:
- Advance notice of scheduled maintenance
- Maintenance windows outside business hours
- Limits on emergency maintenance
- Clear reporting on downtime
- Stronger remedies for repeated failures
Service credits are common, but they are often limited. A small credit on next month’s invoice may not come close to the commercial damage caused by a serious outage.
The key question is whether service credits are stated to be the customer’s only remedy.
Customers should be careful about accepting service credits as the sole remedy where the SaaS platform is business-critical. There may need to be additional rights, including termination rights for repeated, prolonged or high-impact failures.
3. Data protection and security
Most SaaS suppliers process customer data in some form. That makes data protection and security a central negotiation point, not a back-office issue.
Sub-processors are often debated. Suppliers usually want flexibility to add or change hosting providers, support providers and other sub-contractors. Customers may want prior notice, a right to object and confirmation that sub-processors are bound by appropriate data protection terms.
International transfers also need attention. If personal data is transferred outside the UK or EEA, the contract should deal properly with lawful safeguards, such as Standard Contractual Clauses or the UK International Data Transfer Agreement, where relevant.
Security is another pressure point.
Customers, especially those operating in regulated sectors or supplying larger enterprise clients, may ask for audit rights. Suppliers often resist broad on-site audit rights because of security, confidentiality and business disruption concerns.
A practical middle ground may include:
- ISO 27001 or SOC 2 reports
- Security summaries
- Penetration testing summaries
- Written responses to security questionnaires
- Limited audit rights for serious incidents or regulatory requirements
The right position depends on the role of the SaaS platform in the customer’s business.
4. Commercial and operational terms
SaaS contracts often give suppliers the right to change services, terms, features and pricing.
That can be a problem.
A customer may sign up for a specific set of features, controls and integrations, only to find that the supplier can later remove, amend or repackage them.
Customers often negotiate for advance notice of material changes and a right to terminate without penalty where a change has a material adverse effect.
Fee increases also need checking. Many SaaS contracts allow annual price increases, sometimes without a clear cap. Customers may want increases tied to CPI or another agreed measure, with a right to exit if the new pricing is not acceptable.
Exit is another major issue.
Customers need to know what happens when the contract ends. Can they export their data? In what format? How long will the supplier retain it? Will the supplier support migration? Is there a wind-down period?
A good SaaS contract should deal with:
- Data return
- Data deletion
- Export format
- Migration support
- Continued access during transition
- Charges for exit assistance
Without this, the customer may face lock-in, disruption or unexpected costs when trying to move away.
5. IP ownership and customer-derived data
Most SaaS contracts say that each party keeps its pre-existing IP. That part is usually straightforward.
The harder questions are around anything created, generated or learned during the contract.
For example:
- Who owns configurations or custom developments?
- Can the supplier use customer data to improve its platform?
- Can anonymised or aggregated data be used for analytics?
- Who owns reports, outputs or derived insights?
- Are usage patterns, metadata or benchmarking data treated as supplier IP?
These points matter more as SaaS platforms become more data-rich and AI-enabled.
Customers should understand whether their data is simply being processed to provide the service, or whether it is being used to train, improve or commercialise supplier products.
The commercial point
Not every SaaS contract needs heavy negotiation.
A low-cost internal tool will not need the same treatment as a platform that supports customer delivery, regulated operations or sensitive data.
The point is proportionality.
Scaling tech companies should know which SaaS contracts can be accepted quickly, which need review and which need proper negotiation before signature.
The contract should match the risk.
If a SaaS supplier is holding your data, supporting your customers or sitting inside your operating model, the terms are not just legal paperwork. They are part of your risk architecture.
Ethiqs helps scaling tech companies review, negotiate and structure SaaS contracts so the legal position matches the commercial reality.
If you are signing a SaaS deal and the terms do not reflect the risk, speak to us before you commit.