SaaS Liability Caps and Indemnities (UK)

This is the classic SaaS indemnity. The customer wants the supplier to stand behind the proposition that the service can be used without triggering third party IP claims.

The real questions are whether it covers actual claims, legal costs, settlements and judgments, and whether the exclusions are limited to sensible points such as customer modification or use outside the documentation.

• Check that the clause covers defence costs, settlements and judgments for third party claims.
• Check that exclusions are narrow and linked to risk the customer really controls.
• Check what transition help is owed if the supplier modifies, replaces or withdraws the service.

Some customer side indemnity is commercially fair if the customer uploads unlawful material, gives unlawful instructions or misuses the platform. The problem is overreach. Broad drafting can turn the customer into the insurer of the whole service.

Phrases like any and all claims arising out of customer data or use of the service are much wider than most buyers expect when the deal value is agreed.

• Limit the trigger to unlawful content, unlawful instructions or misuse by the customer.
• Prefer to the extent caused by over broader causation language where possible.
• Exclude loss caused by supplier breach, negligence or insecure design.

Teams often assume the DPA solves data liability on its own. It does not. If the supplier is a processor, Article 28 terms, sub processor controls, breach support and end of contract duties must line up with the main liability language.

Article 82 compensation exposure and sub processor liability make it risky to read the DPA and the main cap in isolation from one another.

• Read the DPA, security schedule and main agreement together, not one at a time.
• Check whether the supplier remains responsible for the sub processor chain in a way the contract actually reflects.
• Check whether overseas access or support locations create extra transfer and incident response risk.

An indemnity without claim mechanics is half drafted. The clause should say who gives notice, who controls the defence, who chooses counsel, when settlement consent is needed and what cooperation is required.

Procedural imbalance can turn a protective clause into a dispute trigger long before the underlying claim is resolved.

• Set out notice, defence control and settlement consent clearly.
• Avoid drafting that lets one side spend freely while the other pays later.
• Check whether mitigation duties and information sharing obligations are mutual and workable.

Indemnity value is often lost in the remedy section. A supplier may reserve the right to modify the service, replace it or terminate and refund unused fees. That is not always enough where migration is difficult or the tool is operationally central.

A small refund can be commercially trivial compared with the cost of moving off a deeply embedded system under pressure.

• Check whether the customer gets time to transition if the service has to change or stop.
• Check whether migration support is included, optional or omitted entirely.
• Check whether the clause preserves third party claim cover even if the supplier exits the service.

One of the most common review problems is not abstract law but insurance mismatch. A business may hold professional indemnity, cyber or technology cover and still sign indemnity wording that goes further than the policy responds to.

Limitation and indemnity wording should be checked against real cover, not against assumptions made during procurement.

• Check policy scope, retentions and excluded categories before accepting broad indemnity language.
• Check whether the contract assumes liability the insurer treats as uninsured.
• Check whether the business could absorb the retained risk if the indemnity is called.

A fairer contract keeps supplier side exposure with the supplier where the supplier controls the design, hosting, personnel, code base, sub processor chain and security architecture.

• Service design, code base and IP ownership.
• Provider personnel, hosting choices and the sub processor chain.
• Security architecture, privileged access and incident response design.
• Open source choices, product roadmap changes and feature withdrawals.
• How the service is monitored, patched and supported in day to day operation.

Customer side exposure is more defensible where the customer controls the lawfulness of the data, the instructions given, the local configuration choices and any clear misuse of the platform.

• The lawfulness of uploaded data and the instructions given to the supplier.
• Use outside the documentation, unlawful misuse and local configuration choices.
• Customer side permissions, role mapping and internal access governance.
• Out of scope integrations, downstream use and local operational workarounds.
• The customer's own breach of law or clearly defined use restrictions.

Limitation and exclusion clauses are common in business SaaS and often enforceable, but UCTA still matters. Liability for death or personal injury caused by negligence cannot be excluded, and other limits can face the reasonableness test, especially where one side deals on the other's written standard terms.

Takeaway: Market standard wording is not the same thing as a fair or durable position for this deal.

If the product is sold to consumers rather than a business, the review lens becomes stricter. Digital content standards, fairness rules and the practical enforceability of the liability structure deserve a different and more demanding assessment.

Takeaway: A cap or indemnity framework that might survive in negotiated business paper can look very different in a consumer contract.

If the supplier processes personal data for the customer, Article 28 style terms are not optional and sub processor controls matter. Article 82 compensation exposure means the DPA, security schedule and main liability clause should be read as one package, not as separate admin documents.

Takeaway: Data protection risk allocation works only if the processor terms, the cap and the indemnity point in the same direction.

The core statutory points discussed here apply across England and Wales, Scotland and Northern Ireland, but forum, governing law, enforcement cost and overseas support structures still affect practical leverage. Restricted transfer questions can arise where personal data is made accessible to a separate organisation outside the UK.

Takeaway: The law may be broadly UK wide, but geography still changes bargaining power, enforcement friction and transfer risk.

There is no single magic clause, but balanced SaaS paper usually separates ordinary breach risk from special risk and keeps each party carrying the exposure it is actually placed to control.

• A general cap that reflects the seriousness of the service, not just a token multiple divorced from the real dependency.
• A higher or separate cap for confidentiality, data protection or security where those risks are central to the deal.
• A supplier IP indemnity that covers real third party claims and is not reduced to a token refund.
• A customer indemnity limited to unlawful content, unlawful instructions or misuse, and only to the extent caused by that conduct.
• A clear claim process with notice, defence control, settlement consent and workable cooperation rules.
• Service credits that do not erase other remedies for chronic failure, material breach or serious security issues.
• A risk position that has actually been checked against the parties' real insurance.

Most liability and indemnity problems are not novel. They come from rushed review, poor cross document reading or assumptions that standard supplier paper must be acceptable because it is common.

• Treating the cap figure as the only question and ignoring carve outs.
• Accepting any and all losses language without defining the loss categories properly.
• Letting arising out of wording sweep in loss only loosely connected to the customer's conduct.
• Missing the link between the main agreement, the SLA, the DPA and the security schedule.
• Assuming cheap software means cheap risk.
• Ignoring the sub processor chain and overseas access arrangements.
• Agreeing a position the insurance does not actually support.